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-25 20:03:07
|
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/ |