Re: [ath5k-devel] [PATCH 4/4] ath5k: Implement mac80211 callback set_coverage
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=diffnew=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
Re: [ath5k-devel] [PATCH 4/4] ath5k: Implement mac80211 callback set_coverage
On 9.12.2009 14:30 you wrote: 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. In fact the ping was ping -s 1472 -c 1000 -i 0.002, that's more than 12Mbit/s pushed into the link. Sorry, I shouldn't call it ordinary ping. I didn't say it was perfect, but it couldn't have been completely inaccurate, because I found the athctrl value for 11a mode and Madwifi value for 11g mode that way. Yes, the current formula in Madwifi looks correct. We should use that. OK, I will prepare a revised patch series. However I need to fix the usec to clock conversion in Ath5k before (currently it's correct for 802.11a only). 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
Re: [ath5k-devel] [PATCH 4/4] ath5k: Implement mac80211 callback set_coverage
On 7.12.2009 10:48 you wrote: ACKTimeout is: aSIFSTime + aSlotTime + aPHY-RX-START-Delay 802.11a uses SIFS of 16 µs and 9 µs slot time, that's 25 µs in total. However, the athctrl calculation uses 21 µs ACK timeout for zero distance. And I know the result is correct, as we are using it on 70 links with distances varying between 100m and 8km. I don't say the standard is wrong, just that the hardware might start counting at a different moment than the standard assumes. Of course, the distance settting code in iw probably also needs changing, as it needs to accomodate for aAirPropagationTime being the round trip time, not one-way. Well, according to my interpretation the aAirPropagationTime is the one-way delay. I think it makes sense when we consider the reason the slots are used in CSMA/CA: Station waits a random number of slots. If no other station was transmitting at the beginning of a previous slot, the station starts its own transmit. So the slot time has to be at least the time needed to switch the radio from RX to TX plus the one-way propagation delay, so that every other station can hear the medium is busy on time. Anyway, I think there's only one sure way to determine the correct base ACK timeout for different modes: experiment. It's easy to detect that the ACK timeout is too low - packetloss grows dramatically. The main observation is this: ACK timeout does not depend on slot time! In retrospect it makes sense: station waits only SIFS before sending ACK, not a single slot. The measured values of minimum slot times (with AR5212 and AR5414) are these: 802.11a: 21 µs 802.11b: 27 µs 802.11g: 19 µs I can't give much explanation, the difference of 6 µs between 11a and 11b might be the difference of SIFS (16µs vs. 10µs). 11g uses 10 µs SIFS too, but with additional 6 µs signal extension, maybe that's why the value is closer to 11a than 11b. It's all just guessing, though. So I propose to use 21 µs in 802.11a mode and 27 µs in 802.11b/g mode (as there might be some 802.11b clients and 6µs won't make much difference). What do you think? 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
Re: [ath5k-devel] [PATCH 4/4] ath5k: Implement mac80211 callback set_coverage
On 6.12.2009 19:34 Felix Fietkau wrote: This part is wrong. The slot time can be either short or long, based on configuration and PHY type. I did some test, and the value returned by ath5k_hw_get_slot_time was always 9, even when connected to 802.11b-only AP. I didn't try the turbo mode, though. Unfortunately I don't know how to calculate ACK timeouts for a different slot time - the formula I used is the only one in both Madwifi's and FreeBSD's athctrl. Also the calculation of initial slot time is not expained anywhere, there are only some magic values in initvals.c. 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
