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.

Adrian

Adrian
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
> can
> 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>
>
>
_______________________________________________
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"

Reply via email to