Re: [Madwifi-devel] ramping ping in ad-hoc mode (ticket 1154)
Status: Beta
Brought to you by:
otaku
From: Amy L. <mei...@an...> - 2008-07-26 05:56:50
|
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/ |