On 2009-12-09 2:12 PM, Lukáš Turek wrote: >> 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. That's definitely completely inaccurate. Even before you get packet loss, as you lower the ACK timeout value, you will first start to get an increase in the number of retransmissions. >> 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). Yes, the current formula in Madwifi looks correct. We should use that. - Felix -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
