> On 21 Sep, 2016, at 12:59, Phineas Gage <phineas...@gmail.com> 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.

> The link rate to the ISP's AP, as reported by Mikrotik's admin console, is 
> currently 86.6 Mbps transmit and 144.4 Mbps receive…

> 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 raw link rates are sufficiently above the service provisioning that, bar 
significant changes in geography between you and the access point, antenna 
faults, or really bad weather, you can probably count on getting 40/40 reliably 
at the link level.

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.

 - Jonathan Morton

Codel mailing list

Reply via email to