freebsd stable - Jul 2006 - ath driver transmits frames only after a low watermark is filled

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

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