From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (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 75A6C21F1A9 for ; Thu, 30 Jan 2014 11:29:52 -0800 (PST) Received: from hms-beagle.home.lan ([217.86.112.208]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0Lg5kl-1VSive3ebz-00pYw5 for ; Thu, 30 Jan 2014 20:29:50 +0100 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Sebastian Moeller In-Reply-To: Date: Thu, 30 Jan 2014 20:29:50 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <646BCC1A-0C7A-46AB-827D-717AEA0A2174@gmx.de> References: To: Jeremy Tourville X-Mailer: Apple Mail (2.1510) X-Provags-ID: V03:K0:nhKJEjlpq5mKZmQKzO4KSBsnLLKSPztdgCaj/50tA2k72IkKk1n 12qR9ZLzT6CvudVaiCHa0cY72Ot1rIn5AHj2woamr+zgMzUpBEZvcuzAHRabSamidWk2Z+M mhrEERnu0Bb+lPbxqHqn3YuR7e33OeAf4IveJrQpIA6ZsTtzcMjLvSdvWT6i0+e65kwG7at KdlGI973DRIIbYZtsipFg== Cc: "cerowrt-users@lists.bufferbloat.net" Subject: Re: [Cerowrt-users] SQM Setup and Performance X-BeenThere: cerowrt-users@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Support for user problems regarding cerowrt List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jan 2014 19:29:52 -0000 Hi Jeremy, On Jan 30, 2014, at 18:06 , Jeremy Tourville = wrote: > Hello, I followed your excellent instructions here - > = http://www.bufferbloat.net/projects/cerowrt/wiki/Setting_up_SQM_for_CeroWr= t_310 > =20 > I am using build 3.10.24-8 > =20 > I am using a DSL line rated at 6 Mbps down and 512kbps up. My real = throughput without SQM enabled is 5.7Mbps down and 450kbps up. This looks interesting, the ATM 48 bytes in 53 byte cell = encapsulation used in ADSL only leaves 100*48/53 =3D 90.57% percent of = the specified line rate available for your traffic (but that still = contains further per packet overhead). So I would assume that the actual = liberate is >6.3Mbps? Do you have any chance of verifying the line rate = to the DSLAM? Many modems/dsl-routers have offer a web page that gives = some statistics and information like the line rate. You will need the = line rate as precise as possible if you want to minimize the bandwidth = "sacrifice" needed to keep latencies reasonable (if in doubt err on the = too small side though). > After enabling SQM my throughput has dropped to approximately 4.5Mbps = down and 350 kbps up. =20 So you specified5.7 and 0.45? Then the link layer adaptation = mechanism will try to account for the 48in53 problem and cut down your = available rates by ~10% so the best you can expect is ~5.1 and 0.4. If = you specified 90% of the measured speed you are already at 5.7 * 0.9 = (90% of measured) =3D 5.13 * 0.9 (fixed ATM overhead) =3D 4.617 and 450 = * 0.9 (90% of measured) =3D 405 * 0.9 (fixed ATM overhead) =3D 364.5. So = you can not rally expect much more than you got. > Does this seem like an amount that is expected? (within norms?) > It would seem reasonable that I should expect some performance loss at = the expense of better bufferbloat management based on setting 85-95% of = actual download/upload speeds. Please correct me if I am wrong. :-) Now, my recommendation for ADSL links (well all ATM based links = actually) is to start out with the line rate and reduce from there. (The = ATM link layer adjustment effectively reduces to 90% of link rate = already as explained above) > But my question is, how much is too much? =20 So the multistep procedure is roughly as follows. Start with = full line rate and no link layer adjustments: measure the ping RTT to = the nearest host that responds with no additional traffic; that gives = you the best case latency base line of your link. Next load the link = with a speed test and run the ping again; that gives you a bad case (for = the worst case you need to saturate both up and downlink at the same = time, while measuring the ping RTT). Then activate the link layer = adjustments with your line rates specified and repeat the test under = load; reduce the rates by 5% and repeat. Most likely you will notice = that each reduction in bandwidth will also reduce the latency. You then = can see the different possible bandwidth/latency trade-offs possible on = your link, just pic the one you are most comfortable with. Then use your link normally, but every now and then, when the = link is loaded repeat the ping test and see whether you are still happy, = if not adjust the rates. > The setting of SQM does fix the bufferbloat issue as evidenced by ping = testing and times for packets. With SQM on all packets were 100ms or = less. =20 It is interesting to compare this with the ping time to the same = host without any load on your network. > With SQM off the times jumped to over 500ms or more during the speed = testing.=20 > =20 > For reference I have set the parameters as indicated in the = screenshots. I have changed only two variables and tested after each = change as indicated in the grid below. > =20 > Que setup script Per packet overhead test results > Test #1 simple.qos 40 no buffer, less throughput = <100ms, 4.5mbps down > Test #2 simple.qos 44 no buffer, less throughput = <100ms, 4.5mbps down > Test #3 simplest.qos 40 no buffer, less throughput = <100ms, 4.5mbps down > Test #4 simplest.qos 44 no buffer, less throughput = <100ms, 4.5mbps down simple.qos and simplest.qos should have no real effect on either = latency or bandwidth, matching your results. The overhead is a tiny bit = trickier, if you underestimate the overhead you can, under certain = conditions, still cause buffer bloat in your modem (but these conditions = are tricky to recreate, so underestimation will stochastically show up = as latency spies every now and then under load), if you overestimate the = overhead you sacrifice more bandwidth than necessary (since the overhead = is per packet, this bandwidth sacrifice depends on the typical size of = packets you send). The idea is to just pick the rift values for your = encapsulation and be done with. My current understanding is that 48 bytes is the worst case = overhead, but I have not yet seen a link with that, 44 bytes however are = not uncommon, so 44 is not the worst place to start out with. (Note it = is possible to empirically measure the overhead on your link, and I = would be happy to help you with this, just contact me if interested). > =20 > I also read your statement-=20 > >>>"The CeroWrt development team has been working to nail down a = no-brainer set of instructions for eliminating bufferbloat - the = lag/latency that kills voice & video chat, gaming, and overall network = responsiveness. The hard part is that optimal configuration of the Smart = Queue Management (SQM) link is difficult - there are tons of options an = ISP can set. Although CeroWrt can adapt to any of them, it's difficult = to find out the exact characteristics of the link you have." > =20 > What info do I need to get from my ISP to best optimize my connection? The actual line rates for down- and uplink as well as the full = encapsulation information: DHCP or PPPoE or PPPoA; VC-MUX or LLC/SNAP; = VLAN or no vlan. > =20 > I also recognize that this could be an issue that requires multiple = changes at once. =20 You are doing fine, all it needs is a few = experiments/measurements to find the best values after that you can = basically stick to those. > I am curious to know from the experts what your thoughts are on this. =20= That would be Dave then (all I know about is the atm issues, as = I still have an adel link) Best Regards Sebastian > Many thanks in advance! > =20 > -Jeremy > _______________________________________________ > Cerowrt-users mailing list > Cerowrt-users@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cerowrt-users