On 9.12.2009 02:48 Felix Fietkau wrote: > Twice the propagation time (in microseconds) for a signal to cross the > maximum distance between the most distant allowable STAs that are slot > synchronized. Oh, I missed that... And maybe I'm starting to understand it: the slots are in fact some kind of clock synchronization, recipient gets synchronized with a one-way delay, and then when there's a transmit in the other direction, another one-way delay is added to the "clock".
Unfortunately using this calculation makes us incompatible with FreeBSD and madwifi-ng, however it seems current Madwifi uses the standard calculation: http://madwifi-project.org/changeset/3977/madwifi/branches/madwifi-hal-0.10.5.6/ath/if_ath.c?format=diff&new=3977 And now I'm quite sure the athctrl calculation is completely wrong. Even if it produces correct results :o) > Some hardware internally calculates the ACK timeout based on the > configured slot time. Broadcom does it this way. > Maybe adjusting the ACK timeout without adjusting the slot time works, > but it'll probably interfere with CSMA. Ahteros is not Broadcom, it does not have a firmware, I'm writing the ACK timeout directly into a register of the MAC chip. But you're suggesting what I said in previus mail: we have to understand what the hardware does. And as there is no documentation, the only way is experiment. Most of ath5k was developed this way. > > 802.11a: 21 µs > > 802.11b: 27 µs > > 802.11g: 19 µs > > How did you measure it? Just by gradually lowering the value in ACK timeout register (it's accessible via sysctl in FreeBSD) and testing the link using ordinary ping. When the ACK timeout was too low, packetloss grew from 0% to 50% or so. > I'm guessing that most hardware does have some degree of tolerance for > timing variation. IMHO, if the standard recommends slightly higher but > working values for the same distance, we should use that rather than > experimentally determined limits. The problem is, it's not slightly higher, it's twice or more higher: aSIFSTime + aSlotTime + aPHY-RX-START-Delay is 50 in 802.11a mode, while the default ACK timeout for 802.11a used in ath5k initialisation is 25. And in 802.11b the aPHY-RX-START-Delay alone is defined as 192 µs, while the default used by ath5k is 48. I looked into the current Madwifi sources again, and found they use only aSIFSTime + aSlotTime as ACK timeout. That's 25 for 11a, 30 for 11b and 19 for 11g, so it's in line with my experimental observations and also the 11a ath5k default. Probably the hardware accounts for aPHY-RX-START-Delay itself (it's PHY value, while ACK timeout is MAC chip register). So, what do you think about using the formula from Madwifi? Lukas Turek
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
