From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ea0-f181.google.com (mail-ea0-f181.google.com [209.85.215.181]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id C984F200666 for ; Sat, 9 Feb 2013 11:08:13 -0800 (PST) Received: by mail-ea0-f181.google.com with SMTP id i13so2170604eaa.40 for ; Sat, 09 Feb 2013 11:08:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:content-type; bh=eQb5xxPWweM7QhQ951TSL5BwFzc6syOokZTAP9b+NHE=; b=K6B4fAA5W0+xwiIE+u90GehLu/yg0zO16vC/jBsjTmFz4RFOi388jhR/M7fVjp5wa+ OlZSgnN8XjlqzEZKAHxqjF0xMCM6nZfWm3t7ZQ+25Rceli/4nBWlQllwg/BbaOzes2u0 ZrAuBR1NLMouWMxve2LriiPoht4sRAw9DLBuAWCijlDVZs6ACAFY9ukqF7xZD+YMg4hc rP2T9h3y/FVZlctyK/GqVqafckur/34WZKV6WP7xw3GJIdARwR8CTOjx0u3W3eWwEgvk MfFHFeQTMCxbJsTzN+P/801ho5yXfBuHwBJz0DkJsiDvk7H11EXTVXYnAJrfqAd+w7BO Uwnw== X-Received: by 10.14.193.131 with SMTP id k3mr30352447een.45.1360436891646; Sat, 09 Feb 2013 11:08:11 -0800 (PST) MIME-Version: 1.0 Sender: jeroen.balduyck@gmail.com Received: by 10.14.209.193 with HTTP; Sat, 9 Feb 2013 11:07:41 -0800 (PST) In-Reply-To: References: From: Forums1000 Date: Sat, 9 Feb 2013 20:07:41 +0100 X-Google-Sender-Auth: IJALje8nHPGQxhcFaCp1Li7PwHc Message-ID: To: bloat@lists.bufferbloat.net Content-Type: multipart/alternative; boundary=047d7b343280aa79e104d54f65d1 Subject: [Bloat] I am unable to pinpoint the source of bufferbloat X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Feb 2013 19:08:14 -0000 --047d7b343280aa79e104d54f65d1 Content-Type: text/plain; charset=ISO-8859-1 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 > > --047d7b343280aa79e104d54f65d1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Sebastian,

Thanks for the information. I really appreciate everyo= ne'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 rat= e limit my routers uplink to the cable modem (traffic shaping), I'm mov= ing 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 t= he router *entirely* or are there still some hidden hardware buffers that t= he router's OS cannot "unbloat"? Mikrotik's OS (called Ro= uterOS) is just some flavour of Linux by the way.

Regards,
Jeroen

On Sat, Feb 9, 201= 3 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 l= earned 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 bufferbloa= t? According to the Netalyzr test at http://netalyzr.icsi.berkeley.edu/, I have 5= 50ms of upload bufferbloat. I tried all kinds of stuff on my Windows 7 lapt= op:
>
> - For the Intel(R) 82567LF Gigabit Network Connection, I put receive a= nd transmit buffers to the lowest value of 80 (80 bytes? 80 packets? I don&= #39;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 lapto= p (as both cable modem and Intel NIC are gigabit). Result? Still 550ms of u= pload buffer bloat.

=A0 =A0 =A0 =A0 Netalyzr will only measure the latency of the slowest= component of the path between the test machine and the netalyzr servers, t= ypically 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 t= his is quite conclusive that uplink device has 550ms worth of worst case bu= ffering.


>
> I'm out of ideas now. It seems I can't do anything at all to l= ower bufferbloat. Or the Netalyzr test is broken?:-)

=A0 =A0 =A0 =A0 Unlike typical real traffic, netalyzr uses an inelast= ic unrelenting UDP flood to measure the absolute worst case buffering. Real= traffic typically will try to adjust itself to the existing bandwidth.
=A0 =A0 =A0 =A0 If you follow Dave's advise and put a decent rate limit= er and modern queue management in your router (which by all means you shoul= d), netalyzr will then measure the routers worst case buffering (which will= typically will be even worse than your modem's. 550ms actually is rela= tive decent for home equipment). But for real world cases modern queue mana= gement will make all the difference in the world. So unless your typical us= age includes UDP floods your actual latency is (almost) guaranteed to be mu= ch better. It seems your router is capable of running the current OpenWRT r= elease candidate (ar71xx I would guess, see https://openwrt.org).


best regards
=A0 =A0 =A0 =A0 Sebastian

>
> many thanks for your advice,
> Jeroen
>
> ________________________= _______________________
> Bloat mailing list
> Bloat@lists.bufferbloat= .net
> https://lists.bufferbloat.net/listinfo/bloat


--047d7b343280aa79e104d54f65d1--