[Cerowrt-devel] Proper AQM settings for my connection?

Sat Dec 21 00:38:15 EST 2013

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=32 time=96ms TTL=37
Reply from 54.234.36.13: bytes=32 time=95ms TTL=37
Reply from 54.234.36.13: bytes=32 time=95ms TTL=37
Reply from 54.234.36.13: bytes=32 time=95ms TTL=37
Reply from 54.234.36.13: bytes=32 time=94ms TTL=37
Reply from 54.234.36.13: bytes=32 time=107ms TTL=37
Reply from 54.234.36.13: bytes=32 time=98ms TTL=37
Reply from 54.234.36.13: bytes=32 time=96ms TTL=37
Reply from 54.234.36.13: bytes=32 time=129ms TTL=37
Request timed out.
Reply from 54.234.36.13: bytes=32 time=105ms TTL=37
Reply from 54.234.36.13: bytes=32 time=152ms TTL=37
Reply from 54.234.36.13: bytes=32 time=139ms TTL=37
Request timed out.
Reply from 54.234.36.13: bytes=32 time=96ms TTL=37
Reply from 54.234.36.13: bytes=32 time=98ms TTL=37
Reply from 54.234.36.13: bytes=32 time=98ms TTL=37
Reply from 54.234.36.13: bytes=32 time=156ms TTL=37
Reply from 54.234.36.13: bytes=32 time=153ms TTL=37
Reply from 54.234.36.13: bytes=32 time=118ms TTL=37
Reply from 54.234.36.13: bytes=32 time=166ms TTL=37
Reply from 54.234.36.13: bytes=32 time=176ms TTL=37
Reply from 54.234.36.13: bytes=32 time=160ms TTL=37
Reply from 54.234.36.13: bytes=32 time=138ms TTL=37
Reply from 54.234.36.13: bytes=32 time=150ms TTL=37
Reply from 54.234.36.13: bytes=32 time=182ms TTL=37

pie:

Reply from 54.234.36.13: bytes=32 time=94ms TTL=37
Reply from 54.234.36.13: bytes=32 time=93ms TTL=37
Reply from 54.234.36.13: bytes=32 time=96ms TTL=37
Reply from 54.234.36.13: bytes=32 time=96ms TTL=37
Reply from 54.234.36.13: bytes=32 time=463ms TTL=37
Request timed out.
Reply from 54.234.36.13: bytes=32 time=128ms TTL=37
Request timed out.
Reply from 54.234.36.13: bytes=32 time=108ms TTL=37
Reply from 54.234.36.13: bytes=32 time=97ms TTL=37
Reply from 54.234.36.13: bytes=32 time=93ms TTL=37
Reply from 54.234.36.13: bytes=32 time=100ms TTL=37
Reply from 54.234.36.13: bytes=32 time=144ms TTL=37
Reply from 54.234.36.13: bytes=32 time=174ms TTL=37
Request timed out.
Reply from 54.234.36.13: bytes=32 time=128ms TTL=37
Reply from 54.234.36.13: bytes=32 time=123ms TTL=37
Reply from 54.234.36.13: bytes=32 time=97ms TTL=37

fq_codel:

Reply from 54.234.36.13: bytes=32 time=96ms TTL=37
Reply from 54.234.36.13: bytes=32 time=97ms TTL=37
Reply from 54.234.36.13: bytes=32 time=90ms TTL=37
Reply from 54.234.36.13: bytes=32 time=95ms TTL=37
Reply from 54.234.36.13: bytes=32 time=95ms TTL=37
Reply from 54.234.36.13: bytes=32 time=124ms TTL=37
Reply from 54.234.36.13: bytes=32 time=94ms TTL=37
Reply from 54.234.36.13: bytes=32 time=94ms TTL=37
Reply from 54.234.36.13: bytes=32 time=93ms TTL=37
Reply from 54.234.36.13: bytes=32 time=117ms TTL=37
Reply from 54.234.36.13: bytes=32 time=99ms TTL=37
Reply from 54.234.36.13: bytes=32 time=100ms TTL=37
Reply from 54.234.36.13: bytes=32 time=99ms TTL=37

root at 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 <dave.taht at gmail.com> 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 <richb.hanover at gmail.com> wrote:
>>
>> On Dec 20, 2013, at 11:32 PM, Hector Ordorica <hechacker1 at gmail.com> wrote:
>>
>>> 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_CeroWrt_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. Netalyzr was reporting
>>> 500 msec buffering in both directions.
>>
>> However, I was simultaneously running a ping to Google during that Netalyzr run, and the
>> ping times started at ~55 msec before I started Netalyzr, and occasionally 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’t seem surprised. I’m not sure how to interpret this.
>>
>>> With pie (and default settings), the buffer warnings go away:
>>>
>>> http://n2.netalyzr.icsi.berkeley.edu/summary/id=43ca208a-32182-9424fd6e-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. (See the “Rough Notes” 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 AQM page (say, 85% instead of 95%)?
>>
>> - Can we get more corroboration from the list about the behavior of Netalyzer?
>>
>> Rich
>> _______________________________________________
>> Cerowrt-devel mailing list
>> Cerowrt-devel at lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>
>
>
> --
> Dave Täht
>
> Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html