Re: [Madwifi-devel] ramping ping in ad-hoc mode (ticket 1154)
Status: Beta
Brought to you by:
otaku
Menu
▾
▴
Re: [Madwifi-devel] ramping ping in ad-hoc mode (ticket 1154)
|
From: Amy M. L. <mei...@an...> - 2008-07-29 19:41:53
|
Hello Derek and all,
Following Derek's steps, I can easily create ramping pings for old version.
I found ramping pings disappear in trunk-072408 version. This conclusion is
made after continuously testing for three days. This is really encouraging!
I hope some of you can double check if my observation is correct. Many
thanks to Derek and Bruno again.
Best,
Amy
-----Original Message-----
From: Derek Smithies [mailto:de...@in...]
Sent: Saturday, July 26, 2008 5:21 AM
To: Amy Lu
Cc: 'bruno randolf'; 'Benoit PAPILLAULT'; '????';
mad...@li...
Subject: RE: [Madwifi-devel] ramping ping in ad-hoc mode (ticket 1154)
Hi,
Set bintval while the interface is down, then bring the interface up..
Derek.
On Sat, 26 Jul 2008, Amy Lu wrote:
> Hello Derek, how do you change bintval?
>
> I did "iwpriv ath0 bintval 500" on every test node, but "iwpriv ath0
> get_bintval" always returns 100.
>
> -----Original Message-----
> From: Derek Smithies [mailto:de...@in...]
> Sent: Friday, July 25, 2008 7:14 PM
> To: Amy Lu
> Cc: 'bruno randolf'; 'Benoit PAPILLAULT'; '????';
> mad...@li...
> Subject: RE: [Madwifi-devel] ramping ping in ad-hoc mode (ticket 1154)
>
> Hi,
> Since you are only accepting packets from your network
>> I only accept packets that are generated from the four nodes (by
>> checking the source address of every incoming packet).
> you will probably never get ramping.
>
> ====
> The nodes have to be brought up at as close as possible (less than a
> second variation) the same time. Ramping is more likely to occur with a
> longer beacon interval. In my experience, a bintval of 500 makes it easy
> to achieve ramping. A bintval of 100 is harder. Using a script (as
> described below) helped.
> If they do not start ramping immediately, start again.
>
> I used a script running on a separate box (no radio card) to do the
> following tasks on each of the test nodes. The separate box had lan access
> and ssh keys all set up, so all of the test nodes could be configured at
> exactly the same time.
> The script did the following on each test node:
> *bring all the ath0 interface down,
> *pause 2 sec
> *bring the ath0 interface up
> *pause 5 sec
> *ping one other of the test nodes for 20 pings.
>
> To test for ramping, I wrote a python program to analyse the output of the
> pings. (So I had to process 3 sets of ping results)
>
> It usually takes just two complete cycles before ramping is happening.
>
> To verify that this does get ramping, I suggest you first use a known
> version of the madwifif driver - 2250 say, which does do ramping. Once you
> have shown that it does ramp, and you quickly see what ramping looks like,
> you can test different versions of the madwifi tree.
>
> Using the other approach of achieving ramping ("just waiting") is a bit
> tedious.
>
> Hope this helps,
>
> Derek.
> ================================================================
>
> On Fri, 25 Jul 2008, Amy Lu wrote:
>
>> Hi Derek and all,
>>
>> Thanks for sharing this. This is really encouraging. Lately I finally got
>> some time to revisit the problem of ramping ping. I am trying to follow
>> Derek's method and see if I can get rid of ramping pings. Derek, could
you
>> take a look at my setup? I hope I understand your previous email
> correctly.
>>
>> Here is my setup.
>> Build: madwifi-trunk-r3815-20080724. (I don't know how to use openwrt so
I
>> just stay with madwifi trunk. In fact, I saw some modification for beacon
>> processing in adhoc mode has been added in the trunk. I am hoping this
>> version can work.)
>>
>> Wireless Nodes: four laptops running debian etch, two of which are
> equipped
>> with AR5242 e-minipici card, and the other two are with Linksys pcmcia
> cards
>> (AR5212).
>>
>> Scenario: I bring up the four nodes at roughly the same time and have
node
> A
>> pings node B, and node C pings node D. Rate adaption is off (fixed at
>> 11Mbps). In addition, I do iwpriv ath0 bgscan 0, and athctrl -d 5000 when
> I
>> brought up the nodes.
>>
>> To get rid of foreign nodes, I modify the code in the rx_tasklet so that
I
>> only accept packets that are generated from the four nodes (by checking
> the
>> source address of every incoming packet). Packets from foreign nodes are
>> simply discarded.
>>
>>
>> For now, my experiment has been running more than 24 hours and everything
>> seems going well. The ping time is within several milliseconds. I will
> keep
>> running the experiment for several days and see how it goes.
>>
>>
>> Thanks,
>> Amy
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> -----Original Message-----
>> From: Derek Smithies [mailto:de...@in...]
>> Sent: Thursday, May 29, 2008 6:33 PM
>> To: Amy M. Lu
>> Cc: 'bruno randolf'; 'Benoit PAPILLAULT'; '????';
>> mad...@li...
>> Subject: RE: [Madwifi-devel] ramping ping in ad-hoc mode (ticket 1154)
>>
>> Amy,
>>
>> On my setup, ramping has been obliterated.
>> The two networks I have for testing are not exhibiting ramping, even
after
>> many days of uptime, and numerous tests.
>>
>> Further, the beacons generated from the nodes on each network are in
>> perfect synchronisation, even after many days of uptime. Nodes are
>> correctly choosing when to send beacons. Wireshark dumps of the radio
>> traffic show that adhoc standard for beacon transmission is working -
only
>> some nodes send beacons at the start of a beacon interval.
>>
>> This is encouraging. Previous builds have operated correctly for a day or
>> two. Then the beacon synchronisation fails, and the throughput drops, and
>> ramping comes...
>>
>> The BSSID is a 6 bytes field in beacon and data packets. It's use implies
>> that a node has agreed to the ESSID, capabilities, beacon interval.
>> The BSSID also implies synchronisation with the network's timestamp.
>>
>> Use of a preset, fixed BSSID is unwise. With a fixed BSSID, how can the
>> beacons be adjusted to have the timestamp in sync?
>>
>> After analysing gigabytes of wireshark dump from a node in monitor mode,
I
>> have observed foreign nodes (radio cards I don't have control over)
>> joining the network I have control over. These foreign nodes may (or may
>> not be) working to the same timestamp as the network they have joined.
>>
>> There is (my view) a logical inconsistancy in the driver for adhoc
>> operation. When we receive a data packet from a foreign node, with the
>> BSSID used in our network, (and the foreign node is not in the nbour
>> table), we add this node to our neighbour table. Even though we don't
know
>> if the ESSID/capabilities are acceptable. Even though we don't know if
the
>> foreign node has correctly synced to our network timestamp. Later, on
>> receiving a packet from the foreign node, we act on it as a part of our
>> network. This is too accepting.
>>
>>
>> My build:
>> I am using the OpenWrt build, which is based on r3314.
>> Contained in the openWrt build is a number of patches - all of these I am
>> using.
>>
>> there are a number of interesting patches in the openwrt build - one is:
>>
>
https://dev.openwrt.org/browser/trunk/package/madwifi/patches/332-reset_beac
>> ons.patch?rev=10553
>> which removes a double reset of the hal.
>>
>> Do not merge with a foreign node, just because I have received a data
>> packet from them. Merges only happen after a full check of the foreign
>> node's beacon.
>>
>> Limit the promiscuity of the merge process, so as to only merge when
there
>> is full agreement on the timestamps to use. Thus, I only allow merges to
>> happen with nodes in my network. This condition is required. You see,
>> there are too many foreign nodes out there with broken timestamp handling
>> who will merge with my network - which leads to (in my view) ramping.
>>
>> I am part of a trial program of the HAL discussed on the list a while
ago.
>> Sadly, this HAL is not available for release.
>> I have a report from one other user of this HAL (who would have used it
in
>> a driver without my modifications) and says it ramps.
>>
>> In my view, the prerelease HAL is not sufficient to stop ramping. To stop
>> ramping, you have to find a way to ensure that only good nodes (ones that
>> correctly manage the timestamp) merge to our network.
>>
>> I hope this helps,
>>
>> Derek.
>>
>> On Thu, 29 May 2008, Amy M. Lu wrote:
>>
>>> Hello Bruno, Derek, and all,
>>>
>>> Any update for the problem of ramping pings?
>>>
>>> I just finish up some work, and have some time for helping out
> experiment.
>>> If you have some new patches needed to try out, I can do that.
>>>
>>> Amy
>>>
>>> -----Original Message-----
>>> From: bruno randolf [mailto:br...@th...]
>>> Sent: Monday, March 31, 2008 10:04 PM
>>> To: Benoit PAPILLAULT
>>> Cc: Amy Lu; 'Derek Smithies'; '????';
mad...@li...
>>> Subject: Re: [Madwifi-devel] ramping ping in ad-hoc mode (ticket 1154)
>>>
>>> On Tuesday 01 April 2008 04:47:58 Benoit PAPILLAULT wrote:
>>>> Exactly what I was going to do :-). I'll try to make it work on 5210 as
>>>> well... but that would probably wait next week end :-(
>>>
>>> yeah, its not hard to add, but pointless if we are not going to use it.
>>> as of now i don't see any benefit in using our "own" beacon config
> instead
>>> of
>>> the HALs because it doesn't help to solve the problem.
>>>
>>> bruno
>>>
>>>
>>>
>>>
>>
>> --
>> Derek Smithies Ph.D.
>> IndraNet Technologies Ltd.
>> Email: de...@in...
>> ph +64 3 365 6485
>> Web: http://www.indranet-technologies.com/
>>
>>
>>
>>
>
> --
> Derek Smithies Ph.D.
> IndraNet Technologies Ltd.
> Email: de...@in...
> ph +64 3 365 6485
> Web: http://www.indranet-technologies.com/
>
>
>
>
>
--
Derek Smithies Ph.D.
IndraNet Technologies Ltd.
Email: de...@in...
ph +64 3 365 6485
Web: http://www.indranet-technologies.com/
|