2011/6/29 Adrian Chadd <adr...@freebsd.org>:
> Ok, so!
>
>
> On 29 June 2011 02:30, Robert Högberg <robert.hogb...@gmail.com> wrote:
>> Hello,
>>
>> I have an ath9k compatible wlan nic (TP-Link TL-WN851N v1, pci id:
>> 168c:0023) and every 30 seconds all outgoing packets seem to be
>> blocked/delayed for about 2 seconds (incoming traffic seems to be
>> unaffected). There are no error messages logged by the kernel.
>
> #define AR5416_DEVID_PCI>.......0x0023 /* AR5416 PCI (MB/CB) Owl */
>
> It's an AR5416 PCI device.
>
>> The network freezes are easily seen with ping (here with 0.1 seconds
>> interval):
>>> 64 bytes from 192.168.6.60: icmp_req=657 ttl=64 time=1.62 ms
>>> 64 bytes from 192.168.6.60: icmp_req=658 ttl=64 time=1.56 ms
>>> 64 bytes from 192.168.6.60: icmp_req=659 ttl=64 time=1.39 ms
>>> 64 bytes from 192.168.6.60: icmp_req=660 ttl=64 time=1937 ms
>>> 64 bytes from 192.168.6.60: icmp_req=661 ttl=64 time=1835 ms
>>
>> I believe the source of the problem is the periodic long noise floor
>> calibration in the ath9k driver. Specifically, it looks like it's the
>> function ath9k_hw_loadnf() which causes the problem (If it's not
>> called during calibration then there are no network interruptions).
>
> I've seen long NF calibration passes with the AR5416. This occurs when
> the channel is quite busy. Later chips aren't this bad.
Have you seen NF calibration passes as long as mine? Is it possible to
tweak the NF calibration process in any way to make it a little more
gentle? Except for changing the frequency of the calibrations.
Would it be possible to only perform NF calibrations when signal
strength or some other quality related parameter changes? Or is this
as good as it gets with this chip?
> Now, what ath9k_hw_loadnf() does is:
>
>>......./*
>>....... * Wait for load to complete, should be fast, a few 10s of us.
>>....... * The max delay was changed from an original 250us to 10000us
>>....... * since 250us often results in NF load timeout and causes deaf
>>....... * condition during stress testing 12/12/2009
>>....... */
>
>>.......for (j = 0; j < 10000; j++) {
>>.......>.......if ((REG_READ(ah, AR_PHY_AGC_CONTROL) &
>>.......>....... AR_PHY_AGC_CONTROL_NF) == 0)
>>.......>.......>.......break;
>>.......>.......udelay(10);
>>.......}
>
> It shouldn't be causing your device to block on packets for -that-
> long however. That should only be 100ms. You could try reducing that
> 10000 down to say 100 and see if it reduces the amount of time your
> packets are blocked. But honestly, I don't think it's this. 2000ms is
> quite long.
It seems like the driver never has to wait in that loop. The driver
always breaks out of the loop in the first iteration (j == 0).
If I return from ath9k_hw_loadnf() right before
REG_SET_BIT(ah, AR_PHY_AGC_CONTROL, AR_PHY_AGC_CONTROL_NF);
then I don't have any delayed packets. It seems like that line (which
I guess is the actual NF load command) causes outbound packets to be
blocked for some time.
> Is something performing channel scanning every 30 seconds? That would do it.
No. I've verified that the problem occurs every ATH_LONG_CALINTERVAL
ms. Changing the constant's value changes the frequency of the network
interruptions.
Regards
Robert
_______________________________________________
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
