Date: Sun, 28 Oct 2012 20:48:13 -0700 From: Adrian Chadd <adrian@freebsd.org> To: freebsd-wireless@freebsd.org Subject: updates: net80211/ath now do AP power save "better" (except ps-poll); I broke performance Message-ID: <CAJ-VmokOVNx3hL8Za=_EUu3QRmheDp3BMxxTYtaZFESgiKjeHw@mail.gmail.com>
next in thread | raw e-mail | index | archive | help
Hi! 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. Thanks, Adrian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-VmokOVNx3hL8Za=_EUu3QRmheDp3BMxxTYtaZFESgiKjeHw>