Hi Jonathan,
On Dec 8, 2013, at 20:01 , Jonathan Morton <[email protected]> wrote: > Data point: Annex M ADSL2 can be approximated as 10M down, 2M up in practice. > Throw BitTorrent at that, and round-robin delay absolutely is relevant. ADSL1 > connections will be even more so. Not everyone lives in a city in Scandinavia. Sure, currently at adsl2+ 16M down 2.8M up, I feel the need for a prio system to keep the telephone separated from the rest. > > So a simple tiered scheme which can distinguish VoIP from BitTorrent and both > from general traffic, and applies fq_codel to each tier, is a good idea. So have a look at /usr/lib/aqm/simple.qos, I think Dave has that already prepared for you, all you need to do is make sure that VoIP and BitTorrent packets are properly DiffServ labeled. Now for VoIP that should work well, but for BitTorrent it would be nice if the router could preemptively label those packets. (I guess most torrent clients allow to control the number of flows and the consumed bandwidth, so properly configured torrents would not need any special care, but who can guarantee the "properly configured" part.) But I digress… Best Sebastian > > - Jonathan Morton > On 8 Dec 2013 20:49, "Sebastian Moeller" <[email protected]> wrote: > Hi Juliusz, > > On Dec 8, 2013, at 14:25 , Juliusz Chroboczek > <[email protected]> wrote: > > >>> The promise of fq_codel is that we can get rid of our prioritising > >>> hacks -- if we need that kind of features, then fq_codel has > >>> failed. > > > >> Is that really true? given enough concurrent flows, critical flows > >> might be delayed purely be the round robin scheduling of equally > >> "worthy" packets in fq_codel > > > > At 100 Mbit, one full-size Ethernet frame is 120us. This means that > > if you want your VoIP traffic to have less than 30ms delay, you should > > in principle reach your deadline as long as you have fewer than 250 > > congestion-limited flows at a given time. > > Well, is 250 enough and are the 250 really realistic in a residential > setting? Currently not doing much of anything my router has 142 active > connections (according to conntrack) so 250 might be on the low size for a > device that routes multiple devices. Plus, unfortunately, most residential > internet connections are asymmetric, so on the upload will allow fewer > congestion-limited concurrent flows before the round robin delay will impede > the VOIP session. (In Germany residential VDSL with 100Mbit/s downlink will > run at 40Mbit/s uplink, so hopefully not a big issue, but most cable > providers keep the upload below 10Mbit/s, typically 5Mbit/s for 100Mbit/s > download). So we talk about an order of magnitude fewer flows required to > make phone calls "interesting". > So I still think that for VoIP prioritizing might still be required > until supplied minimum bandwidth gets higher. > > > > >> so some residual priory system might still make sense... > > > > For throughput-sharing reasons, perhaps. For latency reasons, hopefully > > not. > > Even at 1000 symmetric I still think it would be a good idea to > isolate really latency critical traffic from the rest, even if under normal > circumstances there should be no problem, I guess a "better safe than sorry" > approach. But, hey I do not do this for a living so I might be on the wrong > track here. > > best > Sebastian > > > > > -- Juliusz > > _______________________________________________ > Bloat mailing list > [email protected] > https://lists.bufferbloat.net/listinfo/bloat _______________________________________________ Bloat mailing list [email protected] https://lists.bufferbloat.net/listinfo/bloat
