From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ob0-x22c.google.com (mail-ob0-x22c.google.com [IPv6:2607:f8b0:4003:c01::22c]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 9E8FE21F1D4 for ; Fri, 20 Dec 2013 21:38:16 -0800 (PST) Received: by mail-ob0-f172.google.com with SMTP id gq1so3670245obb.31 for ; Fri, 20 Dec 2013 21:38:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=ElDOCeQ9pWe8xsUCO1FbUPz2mShv+tKYMsIoOcjkY+E=; b=mUdOVxRrfbzMD9F+5wVNZgiwl7tpPZdnmUZaxAMGZPUTTp6DUid5Ql/3Q3N5o2tk8J SMti+0OR4YSyBy/20FdryecyfZGm4s3Lyh/dJQ+l2lPSvZkNJM/rXIr3hKYK7lYn4AMX 3lBg0kAKMjRHGyBJuYOeC3udVUGwmyEUx0xffwQ1E4jwEdyFS3Sc/Yv9JxMYtuR1K+dQ jMeibt82VRl4AvvKV0O9O4ree2TtghtkH5Zmrmh//tvz5Ys1ViddfQIpWZPFFyKu0Vhf M4oaGSxo5YHwU6jbWbYpcXg5N413KyGqVP2jG6ZAv4ehZ+hesRN/B13YyJxzwpkurV69 MVOA== MIME-Version: 1.0 X-Received: by 10.60.33.196 with SMTP id t4mr17493oei.81.1387604295736; Fri, 20 Dec 2013 21:38:15 -0800 (PST) Received: by 10.76.9.161 with HTTP; Fri, 20 Dec 2013 21:38:15 -0800 (PST) In-Reply-To: References: <690EEC3B-8E4D-439E-84ED-375104FF2C43@gmail.com> Date: Fri, 20 Dec 2013 21:38:15 -0800 Message-ID: From: Hector Ordorica To: cerowrt-devel@lists.bufferbloat.net Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Cerowrt-devel] Proper AQM settings for my connection? 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: Sat, 21 Dec 2013 05:38:17 -0000 Interesting, I'll upgrade as soon as I have the chance to reconfigure it. Pinging and testing to the same netalyzr server. The replies started to drop during the downlink and uplink tests, except for fq_codel, which remained relatively stable. No AQM: Reply from 54.234.36.13: bytes=3D32 time=3D96ms TTL=3D37 Reply from 54.234.36.13: bytes=3D32 time=3D95ms TTL=3D37 Reply from 54.234.36.13: bytes=3D32 time=3D95ms TTL=3D37 Reply from 54.234.36.13: bytes=3D32 time=3D95ms TTL=3D37 Reply from 54.234.36.13: bytes=3D32 time=3D94ms TTL=3D37 Reply from 54.234.36.13: bytes=3D32 time=3D107ms TTL=3D37 Reply from 54.234.36.13: bytes=3D32 time=3D98ms TTL=3D37 Reply from 54.234.36.13: bytes=3D32 time=3D96ms TTL=3D37 Reply from 54.234.36.13: bytes=3D32 time=3D129ms TTL=3D37 Request timed out. Reply from 54.234.36.13: bytes=3D32 time=3D105ms TTL=3D37 Reply from 54.234.36.13: bytes=3D32 time=3D152ms TTL=3D37 Reply from 54.234.36.13: bytes=3D32 time=3D139ms TTL=3D37 Request timed out. Reply from 54.234.36.13: bytes=3D32 time=3D96ms TTL=3D37 Reply from 54.234.36.13: bytes=3D32 time=3D98ms TTL=3D37 Reply from 54.234.36.13: bytes=3D32 time=3D98ms TTL=3D37 Reply from 54.234.36.13: bytes=3D32 time=3D156ms TTL=3D37 Reply from 54.234.36.13: bytes=3D32 time=3D153ms TTL=3D37 Reply from 54.234.36.13: bytes=3D32 time=3D118ms TTL=3D37 Reply from 54.234.36.13: bytes=3D32 time=3D166ms TTL=3D37 Reply from 54.234.36.13: bytes=3D32 time=3D176ms TTL=3D37 Reply from 54.234.36.13: bytes=3D32 time=3D160ms TTL=3D37 Reply from 54.234.36.13: bytes=3D32 time=3D138ms TTL=3D37 Reply from 54.234.36.13: bytes=3D32 time=3D150ms TTL=3D37 Reply from 54.234.36.13: bytes=3D32 time=3D182ms TTL=3D37 pie: Reply from 54.234.36.13: bytes=3D32 time=3D94ms TTL=3D37 Reply from 54.234.36.13: bytes=3D32 time=3D93ms TTL=3D37 Reply from 54.234.36.13: bytes=3D32 time=3D96ms TTL=3D37 Reply from 54.234.36.13: bytes=3D32 time=3D96ms TTL=3D37 Reply from 54.234.36.13: bytes=3D32 time=3D463ms TTL=3D37 Request timed out. Reply from 54.234.36.13: bytes=3D32 time=3D128ms TTL=3D37 Request timed out. Reply from 54.234.36.13: bytes=3D32 time=3D108ms TTL=3D37 Reply from 54.234.36.13: bytes=3D32 time=3D97ms TTL=3D37 Reply from 54.234.36.13: bytes=3D32 time=3D93ms TTL=3D37 Reply from 54.234.36.13: bytes=3D32 time=3D100ms TTL=3D37 Reply from 54.234.36.13: bytes=3D32 time=3D144ms TTL=3D37 Reply from 54.234.36.13: bytes=3D32 time=3D174ms TTL=3D37 Request timed out. Reply from 54.234.36.13: bytes=3D32 time=3D128ms TTL=3D37 Reply from 54.234.36.13: bytes=3D32 time=3D123ms TTL=3D37 Reply from 54.234.36.13: bytes=3D32 time=3D97ms TTL=3D37 fq_codel: Reply from 54.234.36.13: bytes=3D32 time=3D96ms TTL=3D37 Reply from 54.234.36.13: bytes=3D32 time=3D97ms TTL=3D37 Reply from 54.234.36.13: bytes=3D32 time=3D90ms TTL=3D37 Reply from 54.234.36.13: bytes=3D32 time=3D95ms TTL=3D37 Reply from 54.234.36.13: bytes=3D32 time=3D95ms TTL=3D37 Reply from 54.234.36.13: bytes=3D32 time=3D124ms TTL=3D37 Reply from 54.234.36.13: bytes=3D32 time=3D94ms TTL=3D37 Reply from 54.234.36.13: bytes=3D32 time=3D94ms TTL=3D37 Reply from 54.234.36.13: bytes=3D32 time=3D93ms TTL=3D37 Reply from 54.234.36.13: bytes=3D32 time=3D117ms TTL=3D37 Reply from 54.234.36.13: bytes=3D32 time=3D99ms TTL=3D37 Reply from 54.234.36.13: bytes=3D32 time=3D100ms TTL=3D37 Reply from 54.234.36.13: bytes=3D32 time=3D99ms TTL=3D37 root@cerowrt:~# tc -s qdisc show dev ge00 qdisc htb 1: root refcnt 2 r2q 10 default 10 direct_packets_stat 0 Sent 10342827 bytes 50261 pkt (dropped 2158, overlimits 18307 requeues 0) backlog 0b 0p requeues 0 qdisc fq_codel 110: parent 1:10 limit 600p flows 1024 quantum 300 target 5.0ms interval 100.0ms Sent 10342827 bytes 50261 pkt (dropped 4928, overlimits 0 requeues 0) backlog 0b 0p requeues 0 maxpacket 1514 drop_overlimit 2165 new_flow_count 1568 ecn_mark 0 new_flows_len 0 old_flows_len 1 qdisc ingress ffff: parent ffff:fff1 ---------------- Sent 44097076 bytes 59361 pkt (dropped 81, overlimits 0 requeues 0) backlog 0b 0p requeues 0 Thanks, I'll also look into rrul. On Fri, Dec 20, 2013 at 9:16 PM, Dave Taht wrote: > Netanalyzr is inaccurate. It pushes out a udp stream for not long > enough fpr codel to react, thus giving you an over-estimate, and > furthermore doesn't detect the presence of flow queuing on the link by > sending a secondary flow. This latter problem in netanalyzer is > starting to bug me. They've known they don't detect SFQ, SQF, or > fq_codel or drr for a long time now, these packet schedulers are > deployed at the very least at FT and free.fr and probably quite a few > places more, and detecting it is straightforward. > > Netanalyzr + a ping on the side is all that is needed to see > difference between bloat, aqm, and packet scheduling. > > The rrul test is even better. > > I would be interested in your pie results on the link... > > netanalyzer + a ping -c 60 somewhere in both cases... > > however... there WAS a lot of churn in the AQM code these past few > months, so it is possible you have a busted version of the aqm scripts > as well. a sample of your > > tc -s qdisc show dev ge00 > > would be helpful. As rich says, 3.10.24-5 is pretty good at this > point, and a large number of people have installed it, with only a few > problems (We have a kernel issue that rose it's ugly head again > (instruction traps), and we are discussing improving the web interface > further). > > So upgrade first. > > > > On Fri, Dec 20, 2013 at 9:01 PM, Rich Brown wro= te: >> >> On Dec 20, 2013, at 11:32 PM, Hector Ordorica wro= te: >> >>> I'm running 3.10.13-2 on a WNDR3800, and have used the suggested >>> settings from the latest draft: >>> >>> http://www.bufferbloat.net/projects/cerowrt/wiki/Setting_up_AQM_for_Cer= oWrt_310 >>> >>> I have a 30Mb down / 5Mb upload cable connection. >>> >>> With fq_codel, even undershooting network upload bandwidth by more >>> than 95%, I'm seeing 500ms excessive upload buffering warnings from >>> netalyzr. Download is ok at 130ms. I was previously on a 3.8 release >>> and the same was true. >> >> I have seen the same thing, although with different CeroWrt firmware. Ne= talyzr was reporting >>> 500 msec buffering in both directions. >> >> However, I was simultaneously running a ping to Google during that Netal= yzr run, and the >> ping times started at ~55 msec before I started Netalyzr, and occasional= ly they would bump >> up to 70 or 80 msec, but never the long times that Netzlyzr reported... >> >> I also reported this to the Netalyzr mailing list and they didn=E2=80=99= t seem surprised. I=E2=80=99m not sure how to interpret this. >> >>> With pie (and default settings), the buffer warnings go away: >>> >>> http://n2.netalyzr.icsi.berkeley.edu/summary/id=3D43ca208a-32182-9424fd= 6e-5c5f-42d7-a9ea >>> >>> And the connection performs very well while torrenting and gaming. >>> >>> Should I try new code? Or can I tweak some variables and/or delay >>> options in scripts for codel? >> >> A couple thoughts: >> >> - There have been a bunch of changes between 3.10.13-2 and the current v= ersion (3.10.24-5, which seems pretty stable). You might try upgrading. (Se= e the =E2=80=9CRough Notes=E2=80=9D at the bottom of http://www.bufferbloat= .net/projects/cerowrt/wiki/CeroWrt_310_Release_Notes for the progression of= changes). >> >> - Have you tried a more aggressive decrease to the link speeds on the AQ= M page (say, 85% instead of 95%)? >> >> - Can we get more corroboration from the list about the behavior of Neta= lyzer? >> >> Rich >> _______________________________________________ >> Cerowrt-devel mailing list >> Cerowrt-devel@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/cerowrt-devel > > > > -- > Dave T=C3=A4ht > > Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscrib= e.html