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 <freewis...@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 <adr...@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 > > _______________________________________________ freebsd-wireless@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"