Search Linux Wireless

Re: [PATCH 4/4] ath5k: Implement mac80211 callback set_coverage

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

Attachment: signature.asc
Description: This is a digitally signed message part.


[Index of Archives]     [Linux Host AP]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Linux Kernel]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]
  Powered by Linux