snipped and CC'd for again for record On 05/03/2015, Sebastian Moeller <moell...@gmx.de> wrote: > > On Mar 5, 2015, at 13:55 , Alan Jenkins <alan.christopher.jenk...@gmail.com> > wrote: > >> On 05/03/2015, Sebastian Moeller <moell...@gmx.de> wrote: >> >>>> I'm only shaping upload, because I can't measure any improvement >>>> from shaping download. [which seems kinda hopeful for the cause]
>>> Interesting, in my case I need to shape both properly otherwise my >>> netperf-runner rrul test show too high latencies. >> Disregard, I suck. It's not "too high" for me, because I don't use >> anything like voip. But there is 10-20ms in it. >> >> Last time I gave up getting netperf to on debian (it just kept >> stalling out). I ran it on the router, maybe that screwed up the >> measurements. Now I have a Fedora to test with and sqm-scripts is >> definitely living up to the hype :) >> >> unshaped: >> >> 2015-03-05 12:16:06 Testing against netperf-eu.bufferbloat.net (ipv4) >> with 5 simultaneous sessions while pinging 89.243.96.1 (60 seconds in >> each direction) >> ............................................................. >> Download: 10.84 Mbps >> Latency: (in msec, 61 pings, 0.00% packet loss) >> Min: 21.100 >> 10pct: 23.700 >> Median: 34.700 >> Avg: 34.536 >> 90pct: 47.100 >> Max: 54.400 >> >> >> shaped 12500 (and I'm going to use 11500): >> >> Download: 10.14 Mbps >> Latency: (in msec, 61 pings, 0.00% packet loss) >> Min: 20.800 >> 10pct: 21.400 >> Median: 23.900 >> Avg: 24.010 >> 90pct: 26.100 >> Max: 29.900 > > If you install netperf-wrapper > (https://github.com/tohojo/netperf-wrapper) > and run a test like: > date ; ping -c 10 netperf-eu.bufferbloat.net ; ./netperf-wrapper --ipv4 -l > 300 -H netperf-eu.bufferbloat.net rrul -p all_scaled --disable-log -t > your_configuration_name_here > > you should be able to see even bigger improvements for shaped versus > unshaped (the rrul test will try to saturate both up and downlink, or use > /netperfrunner.sh -H netperf-eu.bufferbloat.net to simultaneously load up > and downlink without netperf-wrapper) I expect almost orders of magnitude > improvements ;) I'm being pedantic here, but you're wrong :). netperf-runner only shows 5-7ms difference. That might be part of why I struggled to measure it last time. Unshaped: 2015-03-07 19:13:14 Testing netperf-eu.bufferbloat.net (ipv4) with 4 streams down and up while pinging 89.243.96.1. Takes about 30 seconds. Download: 9.75 Mbps Upload: 0.38 Mbps Latency: (in msec, 32 pings, 0.00% packet loss) Min: 15.000 10pct: 15.700 Median: 30.700 Avg: 32.297 90pct: 45.400 Max: 67.600 Shaped at 11500 (+overhead set to atm, 40 bytes in gui) Download: 8.36 Mbps Upload: 0.41 Mbps Latency: (in msec, 30 pings, 0.00% packet loss) Min: 14.600 10pct: 15.100 Median: 25.400 Avg: 25.487 90pct: 38.600 Max: 41.100 >>>> Dunno what my ISP has deployed (UK ADSL, "thephone.coop" apparently >>>> reselling Talk Talk, presumably "LLU") but it gives me some hope :). >>> >>> If you truly have an adsl >> >> No FTTC here! > > What a pity, ATM encapsulation is awkward, it looked like a decent idea > while the telco networks seemed to converge on all ATM, but with the move to > all ethernet, ATM is a relict a fossil that stubbornly refuses to go the way > of the dodo… VDSL2’s PTM encapsulation is way saner and only costs like 1% > overhead while ATM comes in at ~9% best case (and due to cell padding can be > much worse) > >> >>> as compared to a more modern vdsl link, could I >>> convince you to try the link layer adjustments? If yes, please “holler”; >>> I >>> have some basic tools to empirically figure out the per packet overhead >>> for >>> ATM-based adel links... >> >> I'm very willing to do that. > > Great, so the first step is to collect a large data set of ping probes. > The > attached shell script I like your example graph, it may take me a while to try though. Alan _______________________________________________ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
