Seeking help for Atheros Wi-Fi driver implementation

[Adrian Chadd]

Hi!

So yes, it's likely noise floor calibration / other initial
calibrations and ANI. The initial calibrations do take a while to run.

The TSF timer accuracy shouldn't drift 60uS. I have a feeling there's
a bug that is leading to the AR9300 running slightly off than it
should. I recall reading about it in the commit logs from the QCA
drivers I have access to.

Erk, here it is. God, I remember finding something similar when doing
chip bringup there. What's the contents of registers 0x8244 and
0x824c? Is it drifting in 20MHz /and/ 40MHz mode? I saw a bug that was
fixed a long time ago where the derived rtc clock value was off by
56uS, which is suspiciously close to you.



-adrian



On 9 May 2015 at 13:14, Yi-Hung Wei <freewisher at gmail.com> wrote:
> Hi Adrian,
>
> Thanks for your prompt reply. Now it makes a lot of sense to me. I set
> 'clear destination mask' and all the TXFILT errors go away. Thank you so
> much. I might never get away this bug without your help.
>
> BTW, I found that if I restart my AP, the packet loss rate is higher in the
> first few seconds. It is because of ANI?
>
> Also, I found that the accuracy of TSF timers are not consistent among
> different chips. I have two AR9300 chips and two AR9280 chips. The TSF
> timers seem to be relatively accurate between the same chips. However, for
> every beacon internal (100TU), I observe roughly 60 micro-sec time drift
> between an AR9300 and an AR9280 chip. Is it possible to manipulate the TSF
> clock for better synchronization?
>
> Thanks and hope you have a great weekend!
>
> Best,
>
> -Yi-Hung
>
> On Fri, May 8, 2015 at 5:57 PM, Adrian Chadd <adrian at freebsd.org> wrote:
>>
>> Hi,
>>
>> The MAC does this on TX:
>>
>> * it has a "tx filt" bit in the keycache entry for each MAC you're
>> speaking to;
>> * if the TX header bit "clear TX filt" is set, it clears the TX filter
>> bit for that MAC address;
>> * if the TX filter bit in the keycache entry is set, it fails the TX
>> immediately - with reason TXFILT;
>> * it tries TX'ing; if it fails it sets the appropriate error, and sets
>> the TX filter bit in the keycache.
>>
>> The idea is that if you fail to transmit a frame, you fail subsequent
>> frames to the same destination and let software retransmit them. This
>> is important for software retransmission of non-aggregate traffic -
>> sequence numbers can't be out of order, so you have to fail all the
>> packets so you can retransmit them all in sequence. You can't fail one
>> in the middle of a sequence and then complete subsequent frames, then
>> you'd be transmitting out of order.
>>
>>
>>
>> -adrian
>
>