Am 09.03.2017 um 16:49 schrieb Matthias May: > On 06/03/17 13:38, Johannes Berg wrote: >>> Well it certainly attempts to via stuff like carrier sense. But that >>> is not fool proof and any time two routers hear a frame and both >>> decide to forward it immediately there is a chance that they will >>> both sense the air at the same time, decide that it is clear, and >>> lose both their forwarded frames due to a collision. How often that >>> happens is hard to say but we have observed that exact behavior a few >>> years ago with an 802.11 multicast routing protocol and adding jitter >>> significantly improved reliability. >> I'm really surprised by this since they both should jitter their >> transmissions already between CWmin and CWmax. Is that window somehow really super small for what you're doing? >> >> johannes >> > Isn't CWmin and CWmax only used for retries? > We recently had the problem that on 5MHz channels probe-responses of APs > which can't hear each other (hidden node problem) always collide. > See [1] for a trace showing the problem. > Yellow is the probe-request (and ack on success), the other colours are > 3 APs. > Putting probe-responses on their own queue with it's own timing results > in [2] and seems to make the problem less worse. > However the first frame still always collides, and only subsequent > retries have the randomness of cwmin/cwmax added. > 5MHz channels make the problem worse since frames are 4 times longer. > > I'm currently trying to find a way to add some randomness to the initial > response, which it seems this patchset attempts to solve as well > (different context though). > > [1] http://may.nu/images/problem.png > [2] http://may.nu/images/jittered.png How do you measure this signals ? Maybe the first choose of in the contention window is the same for all nodes caused by simulation, or so ... In general the chance for choosing all nodes the same waiting value is 1/16 * n (for best effort). So for 3 nodes it seems unlikely. But from first look on your pictures, CW seems to work, since the cyan AP is slightly earlier then magenta and green one, which may the distance of some slot times. But of course for hidden stations this (at best) 16 slot times (which may be only 5 to 8 slot times in average) are much shorter than the actual probe response air time. Would they have proper carrier sense they would not collide. The jitter of path request are also only a bit of more gambling, which may help ... at this point the client should probe a smaller set of APs a time, but the APs cannot change their behavior ... But the actual patch fro PREPs have another goal. Since they could only collide, if multiple routes to destination exists, it might help to spread the a bit. But from what I see, every PREP is jittered. Maybe the first PREP should not be artificially delayed, but all following PREPs of this specific PREQ (which mostly only contain redundant routes, without a better ALM). kind regards -- M.Sc. Benjamin Beichler Universität Rostock, Fakultät für Informatik und Elektrotechnik Institut für Angewandte Mikroelektronik und Datentechnik University of Rostock, Department of CS and EE Institute of Applied Microelectronics and CE Richard-Wagner-Straße 31 18119 Rostock Deutschland/Germany phone: +49 (0) 381 498 - 7278 email: Benjamin.Beichler@xxxxxxxxxxxxxx www: http://www.imd.uni-rostock.de/
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
