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

Lukáš Turek
2009-12-09T13:12:45Z

[-- Attachment #1: Type: text/plain, Size: 2786 bytes --]

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 #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]