No, the driver drops frames only on error and otherwise it sends ENOBUFS up
to the nrt layer. This stalls the sender.
Check athratestats in tools/ath. See what the stats are during transmit.
On May 19, 2013 11:54 AM, "Lev Serebryakov" <l...@freebsd.org> wrote:
> Hello, Adrian.
> You wrote 19 мая 2013 г., 19:49:48:
> AC> Ok. So the hardware queue isnt hung. Good!
> AC> The 30mbit is the transmit rate, not throughput. No idea why is isnt
> AC> downgrading though.
> 300! It doesn't downgrading, because it is UDP and it is FreeBSD --
> Linux blocks sendto() on UDP socket when buffers/queue is full, and
> FreeBSD simply discard data and returns. FreeBSD behaves more
> correctly from POSIX point of view, but Linux is more "expectable".
> AC> So lets do more testing to aee if the transmit queue stalls. Also, we
> AC> diagnose the disassociate at some point. Then after that, rate control.
> Logs sent to you should show, that client deassociate in middle of
> process, and it was unexpected :)
> // Black Lion AKA Lev Serebryakov <l...@freebsd.org>
firstname.lastname@example.org mailing list
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"