I've just dumped some power save queue and TIM management changes into
-HEAD.  This allows the stack and driver to correctly (for values of
"correctly") update the TIM based on both the state of the net80211
power save queue _and_ the driver software queue.

It's an interim solution. Mainly because it's racy - multiple transmit
contexts can overlap/preempt between the state change done (ie, when
TIM is tracked in both the net80211 and driver power save handling)
and when the TIM bit update function is called. It's unfortunate, but
a side effect of the current parallelism (or lack thereof) in some
parts of the wireless code.

However, it shouldn't pose a functional problem to people at the present.

The next few things on this list look something like this:

* I'm going to break out the ieee80211_pwrsave() function into a vap
method and then make it just directly call ath_start() here, which
will also set the TIM bit correctly;
* .. which removes the net80211 power save queue management entirely,
as it's just not needed at the moment for ath(4);
* Then once I've finished serialising the TX path in the net80211
stack and figured out what to do about if_start/if_transmt (which
includes fragment handling), the TIM serialisation problem should go
away - however, there's still the question of how to correctly do this
TX path work;
* There's still significant traffic drops when my macbook pro is doing
scanning whilst TCP iperf is going on. I have a feeling I'm expiring
some frames in the software retry / filtered frame list prematurely,
leading to all kinds of traffic pauses when sending BAR and sliding
the TX window across. But yes, since things go off-air for up to 200ms
at a time, the TCP session is bound to back right up from 150+mbit to
a very slow rate.
* ps-poll is still horribly broken. I'll attack this later. If you
have a device that sends ps-poll then please let me know ASAP as I'd
like you to be a test case for this work. I don't have anything that
sends ps-poll right now.

So I encourage people to update and test this. :-)

Now for the problem: I broke throughput. Instead of getting
150Mbit/sec TCP, I now get ~ 100MBit/sec TCP. The culprit is almost
exclusively going to be the TX serialisation. Now, that's easily
tested and I'll do that tomorrow - I can just undo the TX
serialisation and make ath_start() direct dispatch. If this _isn't_
the case, I'll have to spend whatever time needed to figure it out.
But if it is the case, I'll need to figure out how to serialise TX
without that performance drop. So, if you do update to -HEAD, please
keep that in mind.

I do plan on doing some CPU / locking performance work once all the TX
path and serialisation work is done (and before I do ps-poll, as
that's kind of tricky), but I do need to figure that out. It may
require some API changes and I'd like to get those designed, agreed,
implemented and tested before 10.0 is branched or things will be
difficult to MFC.


freebsd-wireless@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"

Reply via email to