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.hano...@gmail.com> wrote: > > On Dec 20, 2013, at 11:32 PM, Hector Ordorica <hechack...@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@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cerowrt-devel -- Dave Täht 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