ath driver transmits frames only after a low watermark is filled

[Dillon]

Sounds like what always happens when crappy power management stuff is 
enabled either on the station or the ap.
I would investigate that first.

Victor Semionov wrote:
> Hello list,
>
> I have a wireless card with an Atheros 5212 chipset and I'm experiencing the 
> following behavior under FreeBSD 6.1:
>
> TCP connections that consist of small short bursts of one-way (transmission) 
> traffic often stall until traffic is received over another TCP connection. 
> For example, if I try to load a small web page, located on the FreeBSD box, 
> over the wireless link, it doesn't load completely, unless I hit return in a 
> concurrent terminal session, or until I request some other file hosted on the 
> FreeBSD box, or until I wait 20 seconds or so. The signal is not low, the two 
> wireless boxes are in the same room.
>
> Higher-bandwidth connections rarely stall. This makes me think there is some 
> kind of low watermark functionality in the hardware/driver that doesn't send 
> frames until a certain number of them have been queued for transmission, or 
> until a frame has been received. Also, I guess this is the reason that the 
> ath module caused the system to freeze at shutdown or when the module is 
> unloaded, unless I do an "ifconfig ath0 down" before unloading - the 
> unloading code is probably waiting for all queued frames to be transmitted, 
> but that never happens.
>
> Sorry for the weak conclusion that is based on assumptions. I'm not familiar 
> with the OS/driver internals and don't know how to investigate further. Is 
> there a sysctl or other setting that controls this behavior, or some other 
> workaround? Any help would be greatly appreciated.
>
> Best regards,
> Victor Semionov
> _______________________________________________
> freebsd-stable at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe at freebsd.org"
>