On Thu, Nov 10, 2011 at 3:55 PM, Denys Fedoryshchenko <denys@xxxxxxxxxx> wrote: > On Thu, 10 Nov 2011 15:40:01 +0100, Helmut Schaa wrote: >>> >>> I think this might also make implementing reservation (tspec) easier. >>> Not sure if anyone wants/needs that though. >> >> Wouldn't it be possible to implement something like this as a qdisc on top >> of >> mq that makes use of the current tx rate per station to distribute >> the airtime >> equitably? >> >> Of course this would require the qdisc to know the tx rate a priori but >> for >> mac80211 drivers we could just use last_tx_rate as an estimate ... Need last_aggregation_depth bytes and packets and last feasible versions of those for an estimate with n. completion rate, perhaps... >> >> Helmut >> -- >> To unsubscribe from this list: send the line "unsubscribe netdev" in >> the body of a message to majordomo@xxxxxxxxxxxxxxx >> More majordomo info at http://vger.kernel.org/majordomo-info.html > > Maybe someone will make something like "tfifo" in future :) Did some of it last weekend. Code doesn't work yet - I mixed in too many of the ideas mentioned in my earlier, longer, more difficult to read missive. Time based queue limits are an important part of the answer, however. Our current fixed packet queue limits are merely a proxy for time. At 100Mbit ethernet, they were 100ms - which is conus distances... and I'd hope that someone more knowledgable than I at these layers take all this on... Two notes: 1) Getting 'time' from the kernel is expensive. And: System time wanders. mac80211 Wifi devices however do export a get_tsf function which could be used as a relative-to-the-queue clock - and we actually don't need accuracy down to the level of get_tsf (25ns) 2) You need to get a timestamp on entry to the first queue and check against the allowable latency on exit from the last. So to construct a tc chain you'd want a tfifo (timestamp on entry), fifot (check timestamp against limit on dequeue), and for the simplest of applications : tfifot (timestamp on entry, check on exit) > And when clients are connected, each have his own queue. Needed, yes. Particularly with mixed g/n, but also to optimize aggregation AND fairness. > > then, for example qdisc add dev wlan0 parent 1:10 handle 10 tfifo limit > 100ms > If packet are older than 100ms will be dropped, or new packets are not > added, if > there is packet older than 100ms are not sent yet. Aside from me calling it 'tfifot last weekend, yes. Though I prefer using 'timelimit' as the key name, to distinguish between previous overloaded uses of the word limit. > > I am not sure that bandwidth will be distributed fairly, it is different > question, > probably each queue should have some "limited chunk of time" to send data. Round robin with random starting points for each cycle through the stations in what I was calling a 'grouper' in the previous mail. > And again, 802.11a/b/g at least are half-duplex and CSMA, and without > polling/TDMA or CTS/RTS tricks > it will be complicated to give guaranteed chunks of time. I *think* but am not sure that what I have described interacts with the EDCA reasonably well. > > P.S. That's just a dream :) > > --- > Network engineer > Denys Fedoryshchenko > > P.O.Box 41553 Jeddah 21531 > Tel: 920023422 > Fax: +966 26501784 > E-Mail: denys@xxxxxxxxxx > -- > To unsubscribe from this list: send the line "unsubscribe linux-wireless" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- Dave Täht SKYPE: davetaht US Tel: 1-239-829-5608 FR Tel: 0638645374 http://www.bufferbloat.net -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
