From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oa0-x230.google.com (mail-oa0-x230.google.com [IPv6:2607:f8b0:4003:c02::230]) (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 D01AA21F1D4 for ; Fri, 20 Dec 2013 21:47:21 -0800 (PST) Received: by mail-oa0-f48.google.com with SMTP id l6so3793352oag.21 for ; Fri, 20 Dec 2013 21:47:21 -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=2rAaJKCecl7jQMu5WOM+1LCATA7CELtZx3L0yB7Ar2s=; b=d6LietE0II8ZF4iEQltjv2PH5pEAukBiBM7lsZ4R5PXoXhA0HBhwgFdDRs/w+leYYb O/LdK3luWhspLHsRWFPdz1oNFfRuo2zMetqsSH1Rpj5mFMYNlXlle591lvq4suqLvLsT BIE9MUirT1zdZ2+TZfUNl1CR2EmtAsiY2TVExKAVREVpZ9tbWefkWrzvPlKW1qWQ4WeZ WOhB4/04hcrA8Ch7RAiMCuVqaMvUAZKnycK3+bXEHT0y+ZWAqavQRtsjhGrq9e3gymDr +bGWxHiWcx88CF3zgfs0hxe3p4vgvb3vam3ku1ra+ikheDHU/f/ikX5ZHmgj3VRl1Rkw a12Q== MIME-Version: 1.0 X-Received: by 10.182.246.39 with SMTP id xt7mr9413362obc.16.1387604840959; Fri, 20 Dec 2013 21:47:20 -0800 (PST) Received: by 10.76.9.161 with HTTP; Fri, 20 Dec 2013 21:47:20 -0800 (PST) In-Reply-To: References: <690EEC3B-8E4D-439E-84ED-375104FF2C43@gmail.com> Date: Fri, 20 Dec 2013 21:47:20 -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:47:22 -0000 And the pie tc if you are interested: root@cerowrt:~# tc -s qdisc show dev ge00 qdisc htb 1: root refcnt 2 r2q 10 default 10 direct_packets_stat 0 Sent 9106696 bytes 50492 pkt (dropped 5317, overlimits 17208 requeues 0) backlog 0b 0p requeues 0 qdisc pie 110: parent 1:10 limit 600p target 19 tupdate 27 alpha 2 beta 20 bytemode 0 ecn Sent 9106696 bytes 50492 pkt (dropped 5317, overlimits 0 requeues 0) backlog 0b 0p requeues 0 prob 0.000000 delay 0 avg_dq_rate 0 ecn_mark 0 qdisc ingress ffff: parent ffff:fff1 ---------------- Sent 44939413 bytes 59735 pkt (dropped 2811, overlimits 0 requeues 0) backlog 0b 0p requeues 0 On Fri, Dec 20, 2013 at 9:38 PM, Hector Ordorica wro= te: > 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 wr= ote: >>> >>> On Dec 20, 2013, at 11:32 PM, Hector Ordorica wr= ote: >>> >>>> 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_Ce= roWrt_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. N= etalyzr was reporting >>>> 500 msec buffering in both directions. >>> >>> However, I was simultaneously running a ping to Google during that Neta= lyzr run, and the >>> ping times started at ~55 msec before I started Netalyzr, and occasiona= lly 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= =99t 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-9424f= d6e-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 = version (3.10.24-5, which seems pretty stable). You might try upgrading. (S= ee the =E2=80=9CRough Notes=E2=80=9D at the bottom of http://www.bufferbloa= t.net/projects/cerowrt/wiki/CeroWrt_310_Release_Notes for the progression o= f changes). >>> >>> - Have you tried a more aggressive decrease to the link speeds on the A= QM page (say, 85% instead of 95%)? >>> >>> - Can we get more corroboration from the list about the behavior of Net= alyzer? >>> >>> 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/subscri= be.html