From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-1" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 9D87F21F18A for ; Tue, 25 Feb 2014 04:08:26 -0800 (PST) Received: from u-089-cab204a2.am1.uni-tuebingen.de ([134.2.89.3]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0Ltqb7-1XH07u1tP3-011FBd for ; Tue, 25 Feb 2014 13:08:23 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Sebastian Moeller In-Reply-To: <530C7AFA.2070101@gmail.com> Date: Tue, 25 Feb 2014 13:08:22 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <247B6C2F-1A7E-41F8-9E59-04419060E702@gmx.de> References: <530C7AFA.2070101@gmail.com> To: Oliver Niesner X-Mailer: Apple Mail (2.1510) X-Provags-ID: V03:K0:koyS3oIWUWA/WZXdKmBhZVd8W26qhPouDAQypPFQHVOQ7hljSff fT7IZm29HekA/eqNohjBR9UfrKNPaKMF8Y0hmNKXnbV0HRMcgBvDlgaTbfmRSM7AqvKrgAv YyPuhHNsekxXcsMGQyi3t1mK6lkG1HTKjhmzE8+U26OdIS6YwMLjibDgW4vm4MDHYDhrLiI QKvn5sYXiRDU85FDAef6A== Cc: cerowrt-devel@lists.bufferbloat.net Subject: Re: [Cerowrt-devel] uplink_buffer_adjustment X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2014 12:08:27 -0000 Hi Oliver, On Feb 25, 2014, at 12:14 , Oliver Niesner = wrote: > Hi list, >=20 > I use cerowrt (3.10.24-8) direct behind my main dsl Router. > SQM is set and performance is good. This is the most important part; you seem happy with the actual = latency under load.=20 > When i used Netalyzr from my smartphone i've got good results. >=20 >> Network buffer measurements (?): Uplink 96 ms, Downlink is good=20 Presumably the smart phone connects to the cerowrt router via = wlan? >=20 > But when i use my notebook i get this: >=20 >> Network buffer measurements (?): Uplink 1200 ms, Downlink is good If you want to change that number neatly reports you will need = to change the limit variable of the fq_codel instance(s) on your uplink = device (ge00), smaller limit values will cause smaller reported = buffering. BUT you should not be concerned about this report at all. = Netalyzr tries to fill the buffers with (relative) high bandwidth = inelastic unrelenting UDP traffic, one could say it represents a DOS = attack better than real traffic. Real traffic be it TCP (by virtue of = the protocol) and even UDP (by virtue of application writers = implementing their own congestion control) will react to packet loss by = reducing the transmit speed. SQM does a good job strategically dropping = packets so that all flows can adapt their bandwidth to the available = total bandwidth. The beauty of codel is that it starts out quite gentle = in a way that is well matched to TCPs congestion avoidance. It will turn = less gentle if the traffic does not respond and congestion stays high. = Netalyzr now is this weird combination of short duration yet unrelenting = traffic. The reason why SQM does not affect the netalyzr probe by much = is that the netalyzr traffic stops before fq_codel has ramped up the = dropping. So what happens is that the probe fills the largest buffer = which is specified by the limit parameter of fq_codel, that defaults to = 1000 packets on cerowrt (once the queue has limit packets all new = packets get dropped, as it resorts to tail dropping, but that really is = just an emergency behavior; under normal loads with a slow link the = queue will never come close to 1000). TL:DR version, netalyzr probes a buffer depth that while = existing has not much relevance on the latency behavior under load for = cerowrt.=20 >>=20 >=20 > I tried even wired connection and set ring buffer rx/tx with ethtool = to 64, but > only minimal change in uplink buffer (1100ms). Good idea but wrong tunable ;) >=20 > Has anyone an idea, what i can try to get better uplink performance? Unless you intend to run yur router under continuous DOS = attacks, I would recommend to ignore netalyzr's buffer measurements (as = they do not reflect cerowrt's behavior under a more realistic load = well).=20 Best Regards Sebastian >=20 > Regards, >=20 > Oliver >=20 > _______________________________________________ > Cerowrt-devel mailing list > Cerowrt-devel@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cerowrt-devel