From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by huchra.bufferbloat.net (Postfix) with ESMTP id 55720208ABD for ; Sun, 6 Jan 2013 13:48:00 -0800 (PST) Received: from mailout-de.gmx.net ([10.1.76.33]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0MRyq4-1TPpNU1lNa-00T9VT for ; Sun, 06 Jan 2013 22:47:58 +0100 Received: (qmail invoked by alias); 06 Jan 2013 21:47:58 -0000 Received: from 75-142-58-156.static.mtpk.ca.charter.com (EHLO hms-beagle.home.lan) [75.142.58.156] by mail.gmx.net (mp033) with SMTP; 06 Jan 2013 22:47:58 +0100 X-Authenticated: #24211782 X-Provags-ID: V01U2FsdGVkX19HuSYexd5HXa/HumKl5UkzKXf1rMUse9TrJk69lh nfxfNfdqODXPU1 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Sebastian Moeller In-Reply-To: Date: Sun, 6 Jan 2013 13:47:49 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <2C3C7E98-AAD6-4B5B-A837-0BF80E9EF4D5@gmx.de> References: To: Dave Taht X-Mailer: Apple Mail (2.1283) X-Y-GMX-Trusted: 0 Cc: "cerowrt-devel@lists.bufferbloat.net" Subject: Re: [Cerowrt-devel] Anyone using PPPoE with Sugarland? 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: Sun, 06 Jan 2013 21:48:00 -0000 Hi Dave, (and sorry William for being off-topic) On Jan 5, 2013, at 21:31 , Dave Taht wrote: > Netanalyzer's metrics are wrong when used with a fair queuing or codel > based system. I tend t disagree, netalyzr still gives a good estimate of the = worst case buffering. I have a hunch that a hierarchical shaper setup = should only treat tcp flows to codel and use something less gentle for = everything else unless proven to be as well behaved a tcp. Being a = layman, I am unsure whether anything except UDP and TCP actually matter. = Maybe fq_codels fq machinery could be combined with another drop = strategy that drops more aggressively to keep UDP in bound (IIRC DNS = used UDP so just rate-policing UDP sounds not like the way forward after = all the buffer bloat experiments bought us). Anyone knows which = protocols are actually relevant? And would white-listing TCP be = preferred over black-listing UDP? (With the usual issues that = black-listing tends to be optimistic, white-listing pessimistic about = the future). (Or could we just cheat on fq_codel and ramp the dropping = faster for flow-buckets (also) containing non-TCP traffic, like = increasing count in larger quantities; that will penalize all traffic = hashed to that bucket, but might be an acceptable price to pay to keep = UDP under tighter control) > They use a single udp flood to measure the "queue" when > in the "fq" portion of fq_codel there are 1024 by default, and when > codel kicks in, queue depth is reduced eventually to a level that tcp > would expect, but has no effect on a single udp flood. Really? I thought that given enough time codel will reign in on = any misbehaving flows it just takes "a bit longer" if the assumption of = the relevant floe's back off strategy is not matched... >=20 > Use a ping vs a big upload as your test, or the rrul test, after > setting your up/download appropriately. But the problem with this approach is that heavy UDP traffic = will still be detrimental to the latency of the router, would it not? = Oh, and please do not take me too serious (or serious at all) since I = will not be able to implement any of this (lack of fluency in C, and = lack of time to implement the TCP UDP separation in tc (plus what would = one use to flow-queue UDP?))? best Sebastian >=20 >=20 >=20 > On Sat, Jan 5, 2013 at 1:37 PM, William Katsak = wrote: >> Hello, >>=20 >> I am experimenting with using Cero/Sugarland on a PPPoE connection, = and can't seem to find a config of simple_qos that works well. >>=20 >> The service is DSL, PPPoE, 3M/768K. Without any qos, the router works = well, as expected. When I try to use simple_qos, the clients have = trouble loading websites (hangs while loading, etc). >>=20 >> Netlyzer shows upstream buffering of about 650ms, consistently. I = have tried various higher and lower values for UPLINK and DOWNLINK, but = nothing seems to help. Anyway, I think 15-20% below link should be fine. >>=20 >> Here is my config: >> UPLINK=3D550 >> DOWNLINK=3D1900 >> DEV=3Difb0 >> IFACE=3Dge00 >> DEPTH=3D42 >> TC=3D/usr/sbin/tc >> FLOWS=3D8000 >> PERTURB=3D"perturb 0" # Permutation is costly, disable >> FLOWS=3D16000 # >> BQL_MAX=3D3000 # it is important to factor this into the RED calc >>=20 >> CEIL=3D$UPLINK >> MTU=3D1492 >> ADSLL=3D"" >> PPOE=3Dyes >>=20 >> Couple of things I am unsure about: >> 1) Should the IFACE be ge00 or pppoe-ge00? >> 2) Should the MTU be the pppoe mtu (1492) or the ethernet (1500) >>=20 >> One last thing: I have the lan split up into VLAN interfaces se00.1, = se00.100, and se00.200. Everything otherwise works as expected with = these, but could the naming be breaking something? >>=20 >> If anyone is willing to share a working configuration it would be = much appreciated. >>=20 >> Thanks, >> Bill Katsak >>=20 >> _______________________________________________ >> Cerowrt-devel mailing list >> Cerowrt-devel@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/cerowrt-devel >=20 >=20 >=20 > --=20 > Dave T=E4ht >=20 > Fixing bufferbloat with cerowrt: = http://www.teklibre.com/cerowrt/subscribe.html > _______________________________________________ > Cerowrt-devel mailing list > Cerowrt-devel@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cerowrt-devel