> 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
- Jonathan Morton
Codel mailing list