Re: [Cake] FreeNet backhaul

[Pete Heist <pete@heistp.net>]

[-- Attachment #1: Type: text/plain, Size: 1528 bytes --]


> On Sep 7, 2018, at 1:03 AM, Jonathan Morton <chromatix99@gmail.com> wrote:
> 
>> On 7 Sep, 2018, at 1:37 am, Pete Heist <pete@heistp.net> wrote:
>> 
>> This router is an old ALIX with kernel 2.6.26, but on the other hand it does have hfsc + esfq (a variant of sfq with host fairness) deployed, so if it’s actually controlling the queue, one might suspect that sfq it could control inter-flow latency at least somewhat.
> 
> ESFQ has two important faults: it doesn't explicitly control the length of individual queues (only tail-drops when a global limit is reached), and it suffers from hash collisions at the full "birthday problem" rate.  So some of your measurement traffic is likely colliding with real traffic and suffering accordingly.

Ah, ok, that is important.

> That still makes ESFQ far better than a dumb FIFO.

I’ve heard tales of the way things were.

As a contrast, the router I’m on: https://www.heistp.net/downloads/vysina_ping.pdf <https://www.heistp.net/downloads/vysina_ping.pdf> The big difference here is this router’s uplink is licensed spectrum full-duplex 100Mbit, whereas Jerab from earlier is 5GHz WiFi (2x NSM5). The shift around June was an upgrade from ALIX to APU.

I haven’t seen evidence yet of backhaul links running at saturation for long periods. When I watch throughputs in real-time I do see pulses though that probably don't show up in the long-term MRTG throughput graphs. I wonder what queue lengths look like at millisecond resolution during these events.

[-- Attachment #2: Type: text/html, Size: 2389 bytes --]