From: Dave Taht <dave.taht@gmail.com>
To: Pete Heist <pete@heistp.net>
Cc: Jonathan Morton <chromatix99@gmail.com>,
Cake List <cake@lists.bufferbloat.net>
Subject: Re: [Cake] FreeNet backhaul
Date: Fri, 7 Sep 2018 06:59:01 -0700 [thread overview]
Message-ID: <CAA93jw5_3_viNeopSga0GXNXdd=89=Z3QuPiMVY1EkhhWJShsg@mail.gmail.com> (raw)
In-Reply-To: <3BA06BE5-FBD2-4FC8-86BB-786679A66147@heistp.net>
you are making me pull out my mrtg stats, I'll post one. In the
debloating universe, 5 minute averages
really obscure the bufferbloat problem. What's important are
drops/marks, reschedules, queue depths, and overlimits. I get about
3000 drops/day (debloats). I wish I could extrapolate what that and
the reschedules means in terms of induced latency on other flows,
easily.
On Fri, Sep 7, 2018 at 3:00 AM Pete Heist <pete@heistp.net> wrote:
>
>
> 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 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.
> _______________________________________________
> Cake mailing list
> Cake@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake
--
Dave Täht
CEO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-669-226-2619
next prev parent reply other threads:[~2018-09-07 13:58 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-06 22:37 Pete Heist
2018-09-06 22:58 ` Dave Taht
2018-09-06 23:03 ` Jonathan Morton
2018-09-07 10:00 ` Pete Heist
2018-09-07 13:59 ` Dave Taht [this message]
2018-09-07 16:02 ` Pete Heist
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.bufferbloat.net/postorius/lists/cake.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAA93jw5_3_viNeopSga0GXNXdd=89=Z3QuPiMVY1EkhhWJShsg@mail.gmail.com' \
--to=dave.taht@gmail.com \
--cc=cake@lists.bufferbloat.net \
--cc=chromatix99@gmail.com \
--cc=pete@heistp.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox