[Bloat] I am unable to pinpoint the source of bufferbloat

[Forums1000 <forums1000@gmail.com>]

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

Hi Sebastian,

Thanks for the information. I really appreciate everyone's efforts to
educate me on this (first time I've used a mailing list so I apologise for
the long quote in my previous reply).
When I rate limit my routers uplink to the cable modem (traffic shaping),
I'm moving the bottleneck to the router, correct?

So a rate limiter alone may make things even worse if the router's TX
buffer is larger than the one in the modem. However, queue management is
not the same as rate limiting I assume? You need both working together?
What I'm asking here, will (let's say CoDel) solve the problem in the
router *entirely* or are there still some hidden hardware buffers that the
router's OS cannot "unbloat"? Mikrotik's OS (called RouterOS) is just some
flavour of Linux by the way.

Regards,
Jeroen

On Sat, Feb 9, 2013 at 7:48 PM, this_is_not_my_name nor_is_this <
moeller0@gmx.de> wrote:

> Hi Jeroen,
>
> even though the experts already chimed in, let me try to elucidate what I
> learned about netalyzr's latency probe.
>
>
> On Feb 9, 2013, at 01:52 , Forums1000 wrote:
>
> > Hi everyone,
> >
> > Can anyone give some tips on how to diagnose the sources of bufferbloat?
> According to the Netalyzr test at http://netalyzr.icsi.berkeley.edu/, I
> have 550ms of upload bufferbloat. I tried all kinds of stuff on my Windows
> 7 laptop:
> >
> > - For the Intel(R) 82567LF Gigabit Network Connection, I put receive and
> transmit buffers to the lowest value of 80 (80 bytes? 80 packets? I don't
> know). I also disabled interrupt moderation.
> > Result? Still 550ms.
> > - Then I connected my laptop directly to my cable modem, bypassing my
> Mikrotik 450G router. Result? Still 550ms of bufferbloat.
> > - Then I put a 100 megabit switch between the cable modem an the laptop
> (as both cable modem and Intel NIC are gigabit). Result? Still 550ms of
> upload buffer bloat.
>
>         Netalyzr will only measure the latency of the slowest component of
> the path between the test machine and the netalyzr servers, typically that
> will be either a cable modem or a del modem. And indeed that component was
> always constant in your measurements as was the latency. So this is quite
> conclusive that uplink device has 550ms worth of worst case buffering.
>
>
> >
> > I'm out of ideas now. It seems I can't do anything at all to lower
> bufferbloat. Or the Netalyzr test is broken?:-)
>
>         Unlike typical real traffic, netalyzr uses an inelastic
> unrelenting UDP flood to measure the absolute worst case buffering. Real
> traffic typically will try to adjust itself to the existing bandwidth.
>         If you follow Dave's advise and put a decent rate limiter and
> modern queue management in your router (which by all means you should),
> netalyzr will then measure the routers worst case buffering (which will
> typically will be even worse than your modem's. 550ms actually is relative
> decent for home equipment). But for real world cases modern queue
> management will make all the difference in the world. So unless your
> typical usage includes UDP floods your actual latency is (almost)
> guaranteed to be much better. It seems your router is capable of running
> the current OpenWRT release candidate (ar71xx I would guess, see
> https://openwrt.org).
>
>
> best regards
>         Sebastian
>
> >
> > many thanks for your advice,
> > Jeroen
> >
> > _______________________________________________
> > Bloat mailing list
> > Bloat@lists.bufferbloat.net
> > https://lists.bufferbloat.net/listinfo/bloat
>
>

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