Bayesian rate control
Hi all, I've been thinking about rate control a bit lately. I've written up some of my thoughts in a blog post (http://www.openias.org/bayesian-wifi-rate-control), but very briefly put I'd like to build a rate control algorithm based on Bayesian statistical inference, possibly by modeling the rate control problem as a "multi-armed bandit" problem and/or using Thompson sampling. A couple of questions for the list: 1. Is there anybody else out there thinking along similar lines? I'd very much like to find collaborators interested in working on this. It could serve as a pretty nice masters thesis problem, for example. 2. What would be the best hardware/software stack to base this work on? I'm thinking the best driver for rate control experimentation would be ath9k, right? If so then a TP-Link TL-WA901ND router (apparently based on Qualcomm QCA956x SOC) with OpenWrt, and a TP-Link TL-WDN4800 PCIe card (apparently based on Atheros AR9380 with PCI ID 168c:0030) for my desktop sounds like a good combo, no? But would I have to run a custom kernel on my desktop then (or can I somehow get by with an Ubuntu standard kernel)? Any other thoughts or pointers are also more than welcome. Many thanks, Björn Smedman
Re: Bayesian rate control
> 1. Is there anybody else out there thinking along similar lines? I'm not aware, but that may not mean much :) > 2. What would be the best hardware/software stack to base this work > on? > > I'm thinking the best driver for rate control experimentation would > be ath9k, right? If so then a TP-Link TL-WA901ND router (apparently > based on Qualcomm QCA956x SOC) with OpenWrt, and a TP-Link TL-WDN4800 > PCIe card (apparently based on Atheros AR9380 with PCI ID 168c:0030) > for my desktop sounds like a good combo, no? Seems reasonable, yes. You wouldn't have VHT, but HT has enough search space to keep you busy ;-) > But would I have to run a custom kernel on my desktop then (or can I > somehow get by with an Ubuntu standard kernel)? You could use a backported driver. https://backports.wiki.kernel.org/ johannes
Re: Bayesian rate control
On Sun, Oct 23, 2016 at 6:57 AM, Björn Smedman wrote: > Hi all, > > I've been thinking about rate control a bit lately. I've written up > some of my thoughts in a blog post > (http://www.openias.org/bayesian-wifi-rate-control), but very briefly It is nice to see some newer thinking here. > put I'd like to build a rate control algorithm based on Bayesian > statistical inference, possibly by modeling the rate control problem > as a "multi-armed bandit" problem and/or using Thompson sampling. The paper on minstrel's design was never widely published. I linked to it here: http://blog.cerowrt.org/post/minstrel/ Looking harder at rate control has long been on my todo list, but at the top of my list to finish first has been the fair queuing (fq_codel) and airtime fairness work. https://blog.tohojo.dk/2016/06/fixing-the-wifi-performance-anomaly-on-ath9k.html#results http://blog.cerowrt.org/post/real_results Once you are statistically hitting more stations, more often, on a more regular basis, with smaller txops, I felt that many things that were perceived as rate control problems would go away, and other things become easier. A basic "fix" to minstrel is to opportunistically sample (which so far as I know, minstrel-blues does), rather than at a fixed rate. btw: I called my early (unpublished) attempt at a "minstrel-2", "bard". :) The now-enormous search space is a big problem in present-day minstrel, followed by excessive retries/latency when sampling, and hidden stations are becoming more and more of a problem as densities go up. (long list of minstrel issues on that first link I posted above). > A couple of questions for the list: > > 1. Is there anybody else out there thinking along similar lines? Yes and no. At the moment I am thinking about the insights from the TCP "BBR" work google just published: (paywalled but at: http://queue.acm.org/app/ ) where they also point to max-plus algebra as being helpful for solving the problems it had. > I'd very much like to find collaborators interested in working on > this. It coruld serve as a pretty nice masters thesis problem, for > example. Please join us over on the make-wifi-fast list. There are more than a few good papers to be had out of it. > > 2. What would be the best hardware/software stack to base this work on? Presently ath9k is the only game in town, and developing/debugging on x86 is the easiest. > I'm thinking the best driver for rate control experimentation would be > ath9k, right? If so then a TP-Link TL-WA901ND router (apparently based > on Qualcomm QCA956x SOC) with OpenWrt, and a TP-Link TL-WDN4800 PCIe > card (apparently based on Atheros AR9380 with PCI ID 168c:0030) for my > desktop sounds like a good combo, no? But would I have to run a custom > kernel on my desktop then (or can I somehow get by with an Ubuntu > standard kernel)? These days I am using a pcengines apu2 as my primary x86 testbed, with ath9k and ath10k cards in it (and one day mt72). The new turris omnia looks like a good platform also. I've been trying to use stuff newer than AR92xx there. Another box I really like is the ubnt uap-lite. Prior to all those, it was the wndr3800, archer c7v2, and nanostation m5s for outdoor work. > > Any other thoughts or pointers are also more than welcome. > > Many thanks, > > Björn Smedman -- Dave Täht Let's go make home routers and wifi faster! With better software! http://blog.cerowrt.org
Re: Bayesian rate control
Hi Johannes, Thanks for the pointers. On Mon, Oct 24, 2016 at 7:28 AM, Johannes Berg wrote: >> I'm thinking the best driver for rate control experimentation would >> be ath9k, right? If so then a TP-Link TL-WA901ND router (apparently >> based on Qualcomm QCA956x SOC) with OpenWrt, and a TP-Link TL-WDN4800 >> PCIe card (apparently based on Atheros AR9380 with PCI ID 168c:0030) >> for my desktop sounds like a good combo, no? > > Seems reasonable, yes. You wouldn't have VHT, but HT has enough search > space to keep you busy ;-) Are there any cards out there that support VHT and use s/w rate control (Minstrel)? Just in case I run out of search space. :P BR Björn
Re: Bayesian rate control
On Mon, 2016-10-24 at 22:17 +0200, Björn Smedman wrote: > > Are there any cards out there that support VHT and use s/w rate > control (Minstrel)? Just in case I run out of search space. :P Maybe something that's usable with brcmsmac? Not sure I'd recommend buying Broadcom NICs though at this point, with them having been bought out and all (and their upstream support is somewhat spotty, so you might have a hard time finding the right NIC) johannes
Re: Bayesian rate control
hiya, there's a tplink RTL81xx 11ac NIC that's growing linux and freebsd support. I believe it's software rate controllable. The intel 7260 and later parts also allow user controllable rate control and provide transmit completion feedback, but I don't know whether it's enough for your needs. Unfortunately the ath10k firmware .. doesn't :( Not by default, anyway. -adrian
Re: Bayesian rate control
> The intel 7260 and later parts also allow user controllable rate > control and provide transmit completion feedback, but I don't know > whether it's enough for your needs. Perhaps. However, existing rate control is *very* tightly coupled to the driver, and it'd be fairly pointless to disentangle just for the sake of playing with a rate control algorithm. Also, the device doesn't support per-frame control nor any kind of sampling-with-table-fallback, only the rate table that you give to the device and update. Btw, mac80211_hwsim with wmediumd doing some medium simulation might also be something to look at for just extending to VHT. And come to think of it, there's this new driver Felix et al have been working on, mt7601u, which also should support proper rate control APIs. johannes
Re: Bayesian rate control
Thomas, Dave, Adrian, Johannes, Thanks for comments and encouragement. I bought the TP-Link TL-WA901ND access point and TP-Link TL-WDN4800 PCIe card. Had no problem getting them talking to each other with ath9k, and the rate table contains 52 entries, so plenty to start out with. I've written a follow-up post about it if anybody's interested: http://www.openias.org/bayesian-wifi-materials-and-methods Cheers, Björn On Wed, Oct 26, 2016 at 7:56 AM, Johannes Berg wrote: > >> The intel 7260 and later parts also allow user controllable rate >> control and provide transmit completion feedback, but I don't know >> whether it's enough for your needs. > > Perhaps. However, existing rate control is *very* tightly coupled to > the driver, and it'd be fairly pointless to disentangle just for the > sake of playing with a rate control algorithm. > > Also, the device doesn't support per-frame control nor any kind of > sampling-with-table-fallback, only the rate table that you give to the > device and update. > > Btw, mac80211_hwsim with wmediumd doing some medium simulation might > also be something to look at for just extending to VHT. > > And come to think of it, there's this new driver Felix et al have been > working on, mt7601u, which also should support proper rate control > APIs. > > johannes
Re: Bayesian rate control
Hi, On 25 October 2016 at 22:56, Johannes Berg wrote: > >> The intel 7260 and later parts also allow user controllable rate >> control and provide transmit completion feedback, but I don't know >> whether it's enough for your needs. > > Perhaps. However, existing rate control is *very* tightly coupled to > the driver, and it'd be fairly pointless to disentangle just for the > sake of playing with a rate control algorithm. > > Also, the device doesn't support per-frame control nor any kind of > sampling-with-table-fallback, only the rate table that you give to the > device and update. Hi, But there is a per-descriptor TX rate table entry in the driver. FreeBSD uses it to implement its rate control for the intel drivers. What am I missing? :) > > Btw, mac80211_hwsim with wmediumd doing some medium simulation might > also be something to look at for just extending to VHT. > > And come to think of it, there's this new driver Felix et al have been > working on, mt7601u, which also should support proper rate control > APIs. -adrian
Re: Bayesian rate control
> But there is a per-descriptor TX rate table entry in the driver. > FreeBSD uses it to implement its rate control for the intel drivers. > > What am I missing? :) Not sure. But there isn't a per-descriptor table in the driver. There's a per-station table, that *can* be used in similar ways, but at least in Linux none of the APIs are hooked up to the general implementation, it's all driver/device-specific code, so it'd be very painful to try to experiment with. johannes
Re: Bayesian rate control
On 15 November 2016 at 01:34, Johannes Berg wrote: > >> But there is a per-descriptor TX rate table entry in the driver. >> FreeBSD uses it to implement its rate control for the intel drivers. >> >> What am I missing? :) > > Not sure. But there isn't a per-descriptor table in the driver. There's > a per-station table, that *can* be used in similar ways, but at least > in Linux none of the APIs are hooked up to the general implementation, > it's all driver/device-specific code, so it'd be very painful to try to > experiment with. Ok. well, we do that. :) I'll let you know how well it works when I'm doing 11ac with the 7260 driver. -adrian