> On Sep 21, 2016, at 1:38 PM, Jonathan Morton <[email protected]> wrote: >> On 21 Sep, 2016, at 12:59, Phineas Gage <[email protected]> wrote: >> >> Question #1: Is it still effective to run fq_codel on our edge router when I >> have a WiFi uplink to the Internet, instead of a cabled connection like >> ADSL? And related to that, is a high quality point-to-point WiFi connection >> indistinguishable from a cabled connection as far as fq_codel is concerned? >> >> Question #2: Assuming the answer to Question #1 is an overall "yes", is it >> then better to have a guaranteed speed from the ISP, instead of having a >> variable but potentially higher speed, so that I can control the queue and >> have fq_codel and HTB prioritization work effectively? > > This is actually a pretty interesting pair of questions. We’ve just been > doing quite a lot of work related to integrating fq_codel (or something very > like it) into the Linux wifi stack, where it has more information about > aggregation and other things, and can therefore make smarter queuing > decisions. > > The very best solution would be for your WISP to integrate this work into > their hardware at each end of the link. It may take a little more time until > that can happen, as the code is very very fresh and still a little raw. > > Until then, I think something like what you’re already doing should work > well. Normally, fq_codel interacts badly with high-performsnce wifi because > it tends to distribute packets alternately to different stations, which tends > to prevent effective aggregation, but this is not a concern for a > point-to-point link where all your traffic goes to and from one station to > another.
So, for example, if one runs fq_codel on a regular AP accessed by multiple stations (using “tc”, above the driver level), this is not necessarily a good idea? And once the driver work is done and the queues are managed at a lower level, will this no longer be the case? >> Option A: We can choose a maximum of 40/40 Mbit with 1:5 aggregation, >> meaning we could get 40 Mbit, but we could also get a lot less at times (8 >> Mbit I assume), depending on other network load. > > The 1:5 aggregation is worth exploring a bit more deeply. Usually this > refers to the ratio between the total bandwidth provisioned across all > customers (in some region and some service class) and the minimum backhaul > capacity within and at the far edge of the ISP’s network. The theory is that > customers tend not to use all of their bandwidth all of the time, though they > do tend to use all of it some of the time. This theory works fairly well in > practice as long as the traffic patterns are not too correlated and are > distributed over a sufficient number of customers. > > In order to be dragged down to 8Mbps, you would have to see all the other > customers sharing your backhaul trying to use 8Mbps or more (on average) at > the same time. This is unlikely to occur often; consider major sportsball > championship final matches, or national disasters such as one we recently had > an anniversary of, as the most likely triggers. Under such circumstances, > you’ll need to step in and manually experiment to find out what works, but > shaping at 8Mbps would be a reasonable default reaction. > > Of more concern to you is how much external load is needed to pull your share > of the backhaul significantly below 40Mbps - or, alternatively, below the > 20Mbps you can get with the more expensive uncontended service. This will > vary depending on how many customers the 5:1 average is spread over - you > can’t actually calculate it from the information given. > > So the question is whether they have a 40/40 backhaul shared among 5 > customers, or a 1G/1G backhaul which they plan to share among up to 125 > customers, each with 40/40 service. I think the latter is a perfectly > reasonable possibility, and would be much more robust than the former option > which would give you a reduction in throughput as soon as *any* of the other > customers on the same backhaul segment did *anything*. > > It’s a question worth asking your WISP. Be ready to point out that you don’t > plan to actually *use* 40Mbps full-time, but that your AQM solution depends > on knowing how much bandwidth is available for when *your* customers randomly > demand it. Thanks a lot for this great information, I’ll ask them more about what’s behind their aggregation ratio. As I mentioned in one reply earlier, I may ask for flexibility in our contract, try the aggregated service, then switch to guaranteed service depending on the actual performance of their network. If I can rate limit to 30/30 and fq_codel, and it’s 99% effective, I’d rather take that than settle for a guaranteed 20/20 on-season and 6/6 off-season to get to the same annual contract price. I see that this is a great place for helpful info about fq_codel. I probably should have “aggregated” (word of the day) my replies to reduce list traffic, so will do so next time if needed. _______________________________________________ Codel mailing list [email protected] https://lists.bufferbloat.net/listinfo/codel
