[rft] please test -HEAD ath; lots of TX changes

[Adrian Chadd]

Right, but you're likely seeing a different issue to "hardware TXQ is stuck."

I think we've solved that. What we're likely seeing now is some odd
buffer exhaustion issues that I haven't yet seen in the driver. -HEAD
is supposed to be limiting how many ath_buf's are queued  per node
_just_ so this particular issue doesn't occur. But it sounds like this
isn't entirely working.

Now, as for the rate related stuff - yes, MCS15 is actually giving
high (99-100%) success rates. But it may not be transmitting MCS15
very often. How busy is the air? Compile up athsurvey and run that
whilst you're doing a test.

I'm going to tidy up the transmit path a little more before I start
working on trying to diagnose why you're seeing the behaviour you are.
But we'll get to it, I promise.

If you see any other transmit queue stuck issues then please let me
know. I want high confidence that we've solved those before I move
onto the next stuff.

Thanks for all your patience!



Adrian

On 19 May 2013 11:37, Lev Serebryakov <lev at freebsd.org> wrote:
> Hello, Adrian.
> You wrote 19 мая 2013 г., 21:38:21:
>
> AC> Compile up athratestats.
>   Ok, Now I can not reproduce problem without rebooting router. It
>  seems, that as it "pickup" N rates once, they work, even if client
>  was pgysically power-cycled. Reboot of router/AP "helps".
>
>   This time working sender prevents station from recovering, and it
>  fails to re-associate till I killed sender (which shows the same
>  300Mbit/s). When I kill sender, station re-associated successufully.
>  It could be seen in logs.
>
>   All time "athratestats" was running each 1 second, log (redirection
>  of stdout) attached.
>
>   Client (notebook) was on AC power, but about after 8 minutes of test
>  it starts to go powersave (according to AP log). I don't know why.
>
>   You could search for ">>>" in main log for some comments on
>  "external" events.
>
> --
> // Black Lion AKA Lev Serebryakov <lev at FreeBSD.org>