[Cerowrt-devel] speedtest.sh script available

[Cerowrt-devel] speedtest.sh script available

[Rich Brown]

I have created a 'speedtest.sh' shell script that simulates the http://speedtest.net, but does it one better.

The default options for the script do a separate TCP_MAERTS and TCP_STREAM for 60 seconds while collecting ping latency. The output of the script shows the down/upload speed as well as a summary of the ping latency, including min, max, average, median, and 10th and 90th percentiles. 

The script makes it easier to optimize my settings because it makes the latency figures more concrete. (I used to eyeball the ping output, saying, "Hmmm. I think there were fewer outliers than before...")

You can see the script on the "Quick Test for Bufferbloat" page on the wiki at:

http://www.bufferbloat.net/projects/cerowrt/wiki/Quick_Test_for_Bufferbloat#Speedtestsh-shell-script

Enjoy!

Rich

Re: [Cerowrt-devel] speedtest.sh script available

[Aaron Wood]

[-- Attachment #1: Type: text/plain, Size: 1962 bytes --]

Nice!  It gives me what I'd expect for my setup, although the TCP rate is
only 2/3 the line rate on DSL (upload is better at 80%).

..............................................................
 Download:  14.09 Mbps
  Latency: (in msec, 62 pings, 0.00% packet loss)
      Min: 30.157
    10pct: 30.691
   Median: 33.412
      Avg: 34.044
    90pct: 36.970
      Max: 48.250
..............................................................
   Upload:  0.87 Mbps
  Latency: (in msec, 57 pings, 8.06% packet loss)
      Min: 30.655
    10pct: 30.744
   Median: 36.658
      Avg: 36.379
    90pct: 41.414
      Max: 46.451

I'm running 21000/1100 as my rate-limiting settings in CeroWRT (3.10.32-12).

That packet loss is what kills my UDP ping streams.  It doesn't seem to
happen if I use the Free.fr box directly, and only shows when I use CeroWRT
as the bottle-neck.

-Aaron


On Tue, Mar 25, 2014 at 4:16 PM, Rich Brown <richb.hanover@gmail.com> wrote:

> I have created a 'speedtest.sh' shell script that simulates the
> http://speedtest.net, but does it one better.
>
> The default options for the script do a separate TCP_MAERTS and TCP_STREAM
> for 60 seconds while collecting ping latency. The output of the script
> shows the down/upload speed as well as a summary of the ping latency,
> including min, max, average, median, and 10th and 90th percentiles.
>
> The script makes it easier to optimize my settings because it makes the
> latency figures more concrete. (I used to eyeball the ping output, saying,
> "Hmmm. I think there were fewer outliers than before...")
>
> You can see the script on the "Quick Test for Bufferbloat" page on the
> wiki at:
>
>
> http://www.bufferbloat.net/projects/cerowrt/wiki/Quick_Test_for_Bufferbloat#Speedtestsh-shell-script
>
> Enjoy!
>
> Rich
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>

[-- Attachment #2: Type: text/html, Size: 2969 bytes --]

Re: [Cerowrt-devel] speedtest.sh script available

[Dave Taht]

I suggest renaming it to something like bloattest, to avoid copyright
and trademark issues. If you can come up with a sexier name,
goferit... (I have had a name in hiding for a while, "lul" - latency
under load,
you are welcome to it)

ahh... my old friend... awk...

If you change the script to use /bin/sh it works directly on cero!

I have longed to have some sort of sane test server infrastructure in
place, tied to a domain that did geographic dns, for a long time. Are
you going to incur any costs in doing this? community driven and
ad-supported seems like a way to go except that shell scripts don't
have ads...

I'd argue in favor of throwing out the first 25 sec of the test if you
aren't already due to speedboost.

1) This is a box connected directly to the internet:

cero2@snapon:~/t$ ./speedtest.sh
Testing against netperf.richb-hanover.com while pinging gstatic.com
(60 seconds in each direction)
.......................................................................
 Download:  261.94 Mbps
  Latency: (in msec, 71 pings, 0.00% packet loss)
      Min: 0.868
    10pct: 0.930
   Median: 1.070
      Avg: 1.056
    90pct: 1.150
      Max: 1.420
.......................................................................
   Upload:  333.91 Mbps
  Latency: (in msec, 71 pings, 0.00% packet loss)
      Min: 0.812
    10pct: 0.900
   Median: 1.020
      Avg: 1.273
    90pct: 2.040
      Max: 2.770

Yes, I'm less than a ms away from gstatic.

cero2@snapon:~/t$ ping gstatic.com
PING gstatic.com (74.125.239.143) 56(84) bytes of data.
64 bytes from nuq05s02-in-f15.1e100.net (74.125.239.143): icmp_req=1
ttl=59 time=0.924 ms
64 bytes from nuq05s02-in-f15.1e100.net (74.125.239.143): icmp_req=2
ttl=59 time=0.915 ms

2) Run from my nuc

d@nuc:~/t$ ./speedtest.sh
Testing against netperf.richb-hanover.com while pinging gstatic.com
(60 seconds in each direction)
.......................................................................
 Download:  21.6 Mbps
  Latency: (in msec, 71 pings, 0.00% packet loss)
      Min: 16.100
    10pct: 16.600
   Median: 19.700
      Avg: 19.966
    90pct: 23.900
      Max: 27.600
.......................................................................
   Upload:  3.55 Mbps
  Latency: (in msec, 71 pings, 0.00% packet loss)
      Min: 15.900
    10pct: 17.500
   Median: 22.800
      Avg: 22.821
    90pct: 26.400
      Max: 32.000

I then tried the armory's comcast connection...

3) Run from cero

root@dave-gw:~# ./speedtest.sh
Testing against netperf.richb-hanover.com while pinging gstatic.com
(60 seconds in each direction)
.............................................................
 Download:  19.48 Mbps
  Latency: (in msec, 61 pings, 0.00% packet loss)
      Min: 16.782
    10pct: 17.921
   Median: 20.288
      Avg: 21.067
    90pct: 25.415
      Max: 38.299
.............................................................
   Upload:  3.92 Mbps++
  Latency: (in msec, 61 pings, 0.00% packet loss)
      Min: 18.355
    10pct: 20.160
   Median: 24.675
      Avg: 24.385
    90pct: 27.600
      Max: 30.972

So we still have some variance in calculating up/download speeds...

4) Run from cero with sqm off:

root@comcast-gw:~# ./speedtest.sh
Testing against netperf.richb-hanover.com while pinging gstatic.com
(60 seconds in each direction)
.............................................................
 Download:  28.1 Mbps

+the sqm system is set to 30000 down

  Latency: (in msec, 61 pings, 0.00% packet loss)
      Min: 17.246
    10pct: 151.227
   Median: 219.129
      Avg: 197.213
    90pct: 230.134
      Max: 237.868
..............................................................
   Upload:  4.55 Mbps
  Latency: (in msec, 62 pings, 0.00% packet loss)
      Min: 16.744
    10pct: 384.688
   Median: 586.156
      Avg: 579.208
    90pct: 755.223
      Max: 872.024

5) for comparison, a rrul test is at
http://snapon.lab.bufferbloat.net/~d/richb-hannover/richb-compare.svg

So not doing 4 up and down at the same time gives you latency results
at max that are quite a bit
larger than a single flow (which makes sense for tcp without
congestion avoidance working)

and microscopic upload performance compared to what the upload along claims.

sqm settings

config queue 'ge00'
    option interface 'ge00'
    option script 'simplest.qos'
    option linklayer 'none'
    option enabled '1'
    option download '30000'
    option upload '4400'
    option qdisc_advanced '1'
    option ingress_ecn 'ECN'
    option egress_ecn 'ECN'
    option qdisc_really_really_advanced '1'
    option iqdisc_opts 'target 5ms'
    option eqdisc_opts 'target 5ms'
    option qdisc 'nfq_codel'




On Tue, Mar 25, 2014 at 8:16 AM, Rich Brown <richb.hanover@gmail.com> wrote:
> I have created a 'speedtest.sh' shell script that simulates the http://speedtest.net, but does it one better.
>
> The default options for the script do a separate TCP_MAERTS and TCP_STREAM for 60 seconds while collecting ping latency. The output of the script shows the down/upload speed as well as a summary of the ping latency, including min, max, average, median, and 10th and 90th percentiles.
>
> The script makes it easier to optimize my settings because it makes the latency figures more concrete. (I used to eyeball the ping output, saying, "Hmmm. I think there were fewer outliers than before...")
>
> You can see the script on the "Quick Test for Bufferbloat" page on the wiki at:
>
> http://www.bufferbloat.net/projects/cerowrt/wiki/Quick_Test_for_Bufferbloat#Speedtestsh-shell-script
>
> Enjoy!
>
> 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

Re: [Cerowrt-devel] speedtest.sh script available

[Dave Taht]

thx for the new test! I like having multiple tests...

I generally don't care about single stream tcp performance much, nor
do I test as much as I should
against targets on the east coast. your netperf server is about 70ms
away, so I tried testing with target 10ms
instead of 5ms with nfq_codel, still with a download setting of 30000.
It does appear as if our recomendations
for a download speed setting, when greater than 20Mbit, are off in the
wrong direction. As for why... well,
a goodly part of the problem is that on ingress the right place for
this stuff is at the ISP... but it might
make sense to go for 120ms as the codel interval in this case...

I like that netperf only eats 15% of cpu on this test when run on cero
at this speed.

Please note that I'm testing a box that has other traffic and
instruction traps...

root@comcast-gw:~# ./speedtest.sh
Testing against netperf.richb-hanover.com while pinging gstatic.com
(60 seconds in each direction)
............................................................
 Download:  23.61 Mbps
  Latency: (in msec, 61 pings, 0.00% packet loss)
      Min: 14.027
    10pct: 16.561
   Median: 20.061
      Avg: 20.345
    90pct: 24.466
      Max: 37.414
.............................................................
   Upload:  3.49 Mbps
  Latency: (in msec, 61 pings, 0.00% packet loss)
      Min: 17.331
    10pct: 18.919
   Median: 22.178
      Avg: 22.814
    90pct: 27.558
      Max: 29.111

Fiddling with fq_codel target 10ms interval 120ms

config queue 'ge00'
        option interface 'ge00'
        option script 'simplest.qos'
        option linklayer 'none'
        option enabled '1'
        option download '30000'
        option upload '4400'
        option qdisc_advanced '1'
        option ingress_ecn 'ECN'
        option egress_ecn 'ECN'
        option qdisc_really_really_advanced '1'
        option iqdisc_opts 'target 10ms interval 120ms'
        option eqdisc_opts 'target 10ms'
        option qdisc 'fq_codel'

 Download:  23.58 Mbps
  Latency: (in msec, 61 pings, 0.00% packet loss)
      Min: 17.227
    10pct: 18.304
   Median: 20.610
      Avg: 21.078
    90pct: 24.135
      Max: 32.095
.............................................................
   Upload:  3.61 Mbps
  Latency: (in msec, 61 pings, 0.00% packet loss)
      Min: 18.416
    10pct: 20.169
   Median: 24.621
      Avg: 24.959
    90pct: 29.372
      Max: 35.057

we seem to basically peak out at this, even changing the target to
15ms interval 120ms
didn't crack 24 down. The upload number is about correct. I had put in
some fixes to htb in newer
releases of cero to make it use larger quantums at higher rates, will
have to try that...

root@comcast-gw:~# ./speedtest.sh
Testing against netperf.richb-hanover.com while pinging gstatic.com
(60 seconds in each direction)
............................................................
 Download:  23.64 Mbps
  Latency: (in msec, 61 pings, 0.00% packet loss)
      Min: 15.789
    10pct: 16.481
   Median: 19.460
      Avg: 19.589
    90pct: 22.696
      Max: 27.628
.............................................................
   Upload:  3.69 Mbps
  Latency: (in msec, 61 pings, 0.00% packet loss)
      Min: 15.846
    10pct: 18.558
   Median: 23.259
      Avg: 23.031
    90pct: 26.258
      Max: 30.311

Bumping it up to 35000 down had bad results:

root@comcast-gw:~# ./speedtest.sh
Testing against netperf.richb-hanover.com while pinging gstatic.com
(60 seconds in each direction)
............................................................
 Download:  27.89 Mbps
  Latency: (in msec, 61 pings, 0.00% packet loss)
      Min: 16.535
    10pct: 37.046
   Median: 193.440
      Avg: 179.146
    90pct: 228.437
      Max: 233.570
.............................................................
   Upload:  3.27 Mbps
  Latency: (in msec, 61 pings, 0.00% packet loss)
      Min: 16.671
    10pct: 18.093
   Median: 23.476
      Avg: 22.854
    90pct: 26.328
      Max: 27.658



On Tue, Mar 25, 2014 at 9:35 AM, Dave Taht <dave.taht@gmail.com> wrote:
> I suggest renaming it to something like bloattest, to avoid copyright
> and trademark issues. If you can come up with a sexier name,
> goferit... (I have had a name in hiding for a while, "lul" - latency
> under load,
> you are welcome to it)
>
> ahh... my old friend... awk...
>
> If you change the script to use /bin/sh it works directly on cero!
>
> I have longed to have some sort of sane test server infrastructure in
> place, tied to a domain that did geographic dns, for a long time. Are
> you going to incur any costs in doing this? community driven and
> ad-supported seems like a way to go except that shell scripts don't
> have ads...
>
> I'd argue in favor of throwing out the first 25 sec of the test if you
> aren't already due to speedboost.
>
> 1) This is a box connected directly to the internet:
>
> cero2@snapon:~/t$ ./speedtest.sh
> Testing against netperf.richb-hanover.com while pinging gstatic.com
> (60 seconds in each direction)
> .......................................................................
>  Download:  261.94 Mbps
>   Latency: (in msec, 71 pings, 0.00% packet loss)
>       Min: 0.868
>     10pct: 0.930
>    Median: 1.070
>       Avg: 1.056
>     90pct: 1.150
>       Max: 1.420
> .......................................................................
>    Upload:  333.91 Mbps
>   Latency: (in msec, 71 pings, 0.00% packet loss)
>       Min: 0.812
>     10pct: 0.900
>    Median: 1.020
>       Avg: 1.273
>     90pct: 2.040
>       Max: 2.770
>
> Yes, I'm less than a ms away from gstatic.
>
> cero2@snapon:~/t$ ping gstatic.com
> PING gstatic.com (74.125.239.143) 56(84) bytes of data.
> 64 bytes from nuq05s02-in-f15.1e100.net (74.125.239.143): icmp_req=1
> ttl=59 time=0.924 ms
> 64 bytes from nuq05s02-in-f15.1e100.net (74.125.239.143): icmp_req=2
> ttl=59 time=0.915 ms
>
> 2) Run from my nuc
>
> d@nuc:~/t$ ./speedtest.sh
> Testing against netperf.richb-hanover.com while pinging gstatic.com
> (60 seconds in each direction)
> .......................................................................
>  Download:  21.6 Mbps
>   Latency: (in msec, 71 pings, 0.00% packet loss)
>       Min: 16.100
>     10pct: 16.600
>    Median: 19.700
>       Avg: 19.966
>     90pct: 23.900
>       Max: 27.600
> .......................................................................
>    Upload:  3.55 Mbps
>   Latency: (in msec, 71 pings, 0.00% packet loss)
>       Min: 15.900
>     10pct: 17.500
>    Median: 22.800
>       Avg: 22.821
>     90pct: 26.400
>       Max: 32.000
>
> I then tried the armory's comcast connection...
>
> 3) Run from cero
>
> root@dave-gw:~# ./speedtest.sh
> Testing against netperf.richb-hanover.com while pinging gstatic.com
> (60 seconds in each direction)
> .............................................................
>  Download:  19.48 Mbps
>   Latency: (in msec, 61 pings, 0.00% packet loss)
>       Min: 16.782
>     10pct: 17.921
>    Median: 20.288
>       Avg: 21.067
>     90pct: 25.415
>       Max: 38.299
> .............................................................
>    Upload:  3.92 Mbps++
>   Latency: (in msec, 61 pings, 0.00% packet loss)
>       Min: 18.355
>     10pct: 20.160
>    Median: 24.675
>       Avg: 24.385
>     90pct: 27.600
>       Max: 30.972
>
> So we still have some variance in calculating up/download speeds...
>
> 4) Run from cero with sqm off:
>
> root@comcast-gw:~# ./speedtest.sh
> Testing against netperf.richb-hanover.com while pinging gstatic.com
> (60 seconds in each direction)
> .............................................................
>  Download:  28.1 Mbps
>
> +the sqm system is set to 30000 down
>
>   Latency: (in msec, 61 pings, 0.00% packet loss)
>       Min: 17.246
>     10pct: 151.227
>    Median: 219.129
>       Avg: 197.213
>     90pct: 230.134
>       Max: 237.868
> ..............................................................
>    Upload:  4.55 Mbps
>   Latency: (in msec, 62 pings, 0.00% packet loss)
>       Min: 16.744
>     10pct: 384.688
>    Median: 586.156
>       Avg: 579.208
>     90pct: 755.223
>       Max: 872.024
>
> 5) for comparison, a rrul test is at
> http://snapon.lab.bufferbloat.net/~d/richb-hannover/richb-compare.svg
>
> So not doing 4 up and down at the same time gives you latency results
> at max that are quite a bit
> larger than a single flow (which makes sense for tcp without
> congestion avoidance working)
>
> and microscopic upload performance compared to what the upload along claims.
>
> sqm settings
>
> config queue 'ge00'
>     option interface 'ge00'
>     option script 'simplest.qos'
>     option linklayer 'none'
>     option enabled '1'
>     option download '30000'
>     option upload '4400'
>     option qdisc_advanced '1'
>     option ingress_ecn 'ECN'
>     option egress_ecn 'ECN'
>     option qdisc_really_really_advanced '1'
>     option iqdisc_opts 'target 5ms'
>     option eqdisc_opts 'target 5ms'
>     option qdisc 'nfq_codel'
>
>
>
>
> On Tue, Mar 25, 2014 at 8:16 AM, Rich Brown <richb.hanover@gmail.com> wrote:
>> I have created a 'speedtest.sh' shell script that simulates the http://speedtest.net, but does it one better.
>>
>> The default options for the script do a separate TCP_MAERTS and TCP_STREAM for 60 seconds while collecting ping latency. The output of the script shows the down/upload speed as well as a summary of the ping latency, including min, max, average, median, and 10th and 90th percentiles.
>>
>> The script makes it easier to optimize my settings because it makes the latency figures more concrete. (I used to eyeball the ping output, saying, "Hmmm. I think there were fewer outliers than before...")
>>
>> You can see the script on the "Quick Test for Bufferbloat" page on the wiki at:
>>
>> http://www.bufferbloat.net/projects/cerowrt/wiki/Quick_Test_for_Bufferbloat#Speedtestsh-shell-script
>>
>> Enjoy!
>>
>> 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



-- 
Dave Täht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html

Re: [Cerowrt-devel] speedtest.sh script available

[Dave Taht]

aaron: tcp is highly sensitive to RTT and I imagine the rtt from paris
to his server is rather high. See
what happens via demo.tohojo.dk which is much closer to you.

(ping times between there and rich's server would be good to have)



On Tue, Mar 25, 2014 at 9:09 AM, Aaron Wood <woody77@gmail.com> wrote:
> Nice!  It gives me what I'd expect for my setup, although the TCP rate is
> only 2/3 the line rate on DSL (upload is better at 80%).
>
> ..............................................................
>  Download:  14.09 Mbps
>   Latency: (in msec, 62 pings, 0.00% packet loss)
>       Min: 30.157
>     10pct: 30.691
>    Median: 33.412
>       Avg: 34.044
>     90pct: 36.970
>       Max: 48.250
> ..............................................................
>    Upload:  0.87 Mbps
>   Latency: (in msec, 57 pings, 8.06% packet loss)
>       Min: 30.655
>     10pct: 30.744
>    Median: 36.658
>       Avg: 36.379
>     90pct: 41.414
>       Max: 46.451
>
> I'm running 21000/1100 as my rate-limiting settings in CeroWRT (3.10.32-12).
>
> That packet loss is what kills my UDP ping streams.  It doesn't seem to
> happen if I use the Free.fr box directly, and only shows when I use CeroWRT
> as the bottle-neck.
>
> -Aaron
>
>
> On Tue, Mar 25, 2014 at 4:16 PM, Rich Brown <richb.hanover@gmail.com> wrote:
>>
>> I have created a 'speedtest.sh' shell script that simulates the
>> http://speedtest.net, but does it one better.
>>
>> The default options for the script do a separate TCP_MAERTS and TCP_STREAM
>> for 60 seconds while collecting ping latency. The output of the script shows
>> the down/upload speed as well as a summary of the ping latency, including
>> min, max, average, median, and 10th and 90th percentiles.
>>
>> The script makes it easier to optimize my settings because it makes the
>> latency figures more concrete. (I used to eyeball the ping output, saying,
>> "Hmmm. I think there were fewer outliers than before...")
>>
>> You can see the script on the "Quick Test for Bufferbloat" page on the
>> wiki at:
>>
>>
>> http://www.bufferbloat.net/projects/cerowrt/wiki/Quick_Test_for_Bufferbloat#Speedtestsh-shell-script
>>
>> Enjoy!
>>
>> Rich
>> _______________________________________________
>> Cerowrt-devel mailing list
>> Cerowrt-devel@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>
>
>
> _______________________________________________
> 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

Re: [Cerowrt-devel] speedtest.sh script available

[Dave Taht]

running a test to snapon (15ms away) gives me much better results for
a single tcp flow and downloads
set to 30000

(rich: is ecn enabled on your server?)

root@comcast-gw:~# ./speedtest.sh -H snapon.lab.bufferbloat.net
Testing against snapon.lab.bufferbloat.net while pinging gstatic.com
(60 seconds in each direction)
............................................................
 Download:  27.63 Mbps
  Latency: (in msec, 61 pings, 0.00% packet loss)
      Min: 16.205
    10pct: 18.351
   Median: 20.750
      Avg: 21.596
    90pct: 24.881
      Max: 33.364
............................................................
   Upload:  4.13 Mbps
  Latency: (in msec, 61 pings, 0.00% packet loss)
      Min: 16.092
    10pct: 20.611
   Median: 24.177
      Avg: 23.993
    90pct: 26.961
      Max: 31.142



On Tue, Mar 25, 2014 at 10:13 AM, Dave Taht <dave.taht@gmail.com> wrote:
> aaron: tcp is highly sensitive to RTT and I imagine the rtt from paris
> to his server is rather high. See
> what happens via demo.tohojo.dk which is much closer to you.
>
> (ping times between there and rich's server would be good to have)
>
>
>
> On Tue, Mar 25, 2014 at 9:09 AM, Aaron Wood <woody77@gmail.com> wrote:
>> Nice!  It gives me what I'd expect for my setup, although the TCP rate is
>> only 2/3 the line rate on DSL (upload is better at 80%).
>>
>> ..............................................................
>>  Download:  14.09 Mbps
>>   Latency: (in msec, 62 pings, 0.00% packet loss)
>>       Min: 30.157
>>     10pct: 30.691
>>    Median: 33.412
>>       Avg: 34.044
>>     90pct: 36.970
>>       Max: 48.250
>> ..............................................................
>>    Upload:  0.87 Mbps
>>   Latency: (in msec, 57 pings, 8.06% packet loss)
>>       Min: 30.655
>>     10pct: 30.744
>>    Median: 36.658
>>       Avg: 36.379
>>     90pct: 41.414
>>       Max: 46.451
>>
>> I'm running 21000/1100 as my rate-limiting settings in CeroWRT (3.10.32-12).
>>
>> That packet loss is what kills my UDP ping streams.  It doesn't seem to
>> happen if I use the Free.fr box directly, and only shows when I use CeroWRT
>> as the bottle-neck.
>>
>> -Aaron
>>
>>
>> On Tue, Mar 25, 2014 at 4:16 PM, Rich Brown <richb.hanover@gmail.com> wrote:
>>>
>>> I have created a 'speedtest.sh' shell script that simulates the
>>> http://speedtest.net, but does it one better.
>>>
>>> The default options for the script do a separate TCP_MAERTS and TCP_STREAM
>>> for 60 seconds while collecting ping latency. The output of the script shows
>>> the down/upload speed as well as a summary of the ping latency, including
>>> min, max, average, median, and 10th and 90th percentiles.
>>>
>>> The script makes it easier to optimize my settings because it makes the
>>> latency figures more concrete. (I used to eyeball the ping output, saying,
>>> "Hmmm. I think there were fewer outliers than before...")
>>>
>>> You can see the script on the "Quick Test for Bufferbloat" page on the
>>> wiki at:
>>>
>>>
>>> http://www.bufferbloat.net/projects/cerowrt/wiki/Quick_Test_for_Bufferbloat#Speedtestsh-shell-script
>>>
>>> Enjoy!
>>>
>>> Rich
>>> _______________________________________________
>>> Cerowrt-devel mailing list
>>> Cerowrt-devel@lists.bufferbloat.net
>>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>>
>>
>>
>> _______________________________________________
>> 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



-- 
Dave Täht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html

Re: [Cerowrt-devel] speedtest.sh script available

[Sebastian Moeller]

Hi List,


On Mar 25, 2014, at 17:35 , Dave Taht <dave.taht@gmail.com> wrote:

> I suggest renaming it to something like bloattest, to avoid copyright
> and trademark issues. If you can come up with a sexier name,
> goferit... (I have had a name in hiding for a while, "lul" - latency
> under load,
> you are welcome to it)
> 
> ahh... my old friend... awk...
> 
> If you change the script to use /bin/sh it works directly on cero!
> 
> I have longed to have some sort of sane test server infrastructure in
> place, tied to a domain that did geographic dns, for a long time. Are
> you going to incur any costs in doing this? community driven and
> ad-supported seems like a way to go except that shell scripts don't
> have ads...
> 
> I'd argue in favor of throwing out the first 25 sec of the test if you
> aren't already due to speedboost.
> 
> 1) This is a box connected directly to the internet:
> 
> cero2@snapon:~/t$ ./speedtest.sh
> Testing against netperf.richb-hanover.com while pinging gstatic.com
> (60 seconds in each direction)
> .......................................................................
> Download:  261.94 Mbps
>  Latency: (in msec, 71 pings, 0.00% packet loss)
>      Min: 0.868
>    10pct: 0.930
>   Median: 1.070
>      Avg: 1.056
>    90pct: 1.150
>      Max: 1.420
> .......................................................................
>   Upload:  333.91 Mbps
>  Latency: (in msec, 71 pings, 0.00% packet loss)
>      Min: 0.812
>    10pct: 0.900
>   Median: 1.020
>      Avg: 1.273
>    90pct: 2.040
>      Max: 2.770
> 
> Yes, I'm less than a ms away from static.

	I think selecting gstac is a very good choice; it seems to be "replicated" around the globe, as I am 6 ms away (on ethernet that is):

--- gstatic.com ping statistics ---
10 packets transmitted, 10 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 6.087/6.327/6.438/0.129 ms

Now netperf.richb-hanover.com is slightly farther away...

--- atl.richb-hanover.com ping statistics ---
10 packets transmitted, 10 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 113.298/113.458/113.933/0.173 ms

> 
> cero2@snapon:~/t$ ping gstatic.com
> PING gstatic.com (74.125.239.143) 56(84) bytes of data.
> 64 bytes from nuq05s02-in-f15.1e100.net (74.125.239.143): icmp_req=1
> ttl=59 time=0.924 ms
> 64 bytes from nuq05s02-in-f15.1e100.net (74.125.239.143): icmp_req=2
> ttl=59 time=0.915 ms
> 
> 2) Run from my nuc
> 
> d@nuc:~/t$ ./speedtest.sh
> Testing against netperf.richb-hanover.com while pinging gstatic.com
> (60 seconds in each direction)
> .......................................................................
> Download:  21.6 Mbps
>  Latency: (in msec, 71 pings, 0.00% packet loss)
>      Min: 16.100
>    10pct: 16.600
>   Median: 19.700
>      Avg: 19.966
>    90pct: 23.900
>      Max: 27.600
> .......................................................................
>   Upload:  3.55 Mbps
>  Latency: (in msec, 71 pings, 0.00% packet loss)
>      Min: 15.900
>    10pct: 17.500
>   Median: 22.800
>      Avg: 22.821
>    90pct: 26.400
>      Max: 32.000
> 
> I then tried the armory's comcast connection...
> 
> 3) Run from cero
> 
> root@dave-gw:~# ./speedtest.sh
> Testing against netperf.richb-hanover.com while pinging gstatic.com
> (60 seconds in each direction)
> .............................................................
> Download:  19.48 Mbps
>  Latency: (in msec, 61 pings, 0.00% packet loss)
>      Min: 16.782
>    10pct: 17.921
>   Median: 20.288
>      Avg: 21.067
>    90pct: 25.415
>      Max: 38.299
> .............................................................
>   Upload:  3.92 Mbps++
>  Latency: (in msec, 61 pings, 0.00% packet loss)
>      Min: 18.355
>    10pct: 20.160
>   Median: 24.675
>      Avg: 24.385
>    90pct: 27.600
>      Max: 30.972
> 
> So we still have some variance in calculating up/download speeds...
> 
> 4) Run from cero with sqm off:
> 
> root@comcast-gw:~# ./speedtest.sh
> Testing against netperf.richb-hanover.com while pinging gstatic.com
> (60 seconds in each direction)
> .............................................................
> Download:  28.1 Mbps
> 
> +the sqm system is set to 30000 down
> 
>  Latency: (in msec, 61 pings, 0.00% packet loss)
>      Min: 17.246
>    10pct: 151.227
>   Median: 219.129
>      Avg: 197.213
>    90pct: 230.134
>      Max: 237.868
> ..............................................................
>   Upload:  4.55 Mbps
>  Latency: (in msec, 62 pings, 0.00% packet loss)
>      Min: 16.744
>    10pct: 384.688
>   Median: 586.156
>      Avg: 579.208
>    90pct: 755.223
>      Max: 872.024
> 
> 5) for comparison, a rrul test is at
> http://snapon.lab.bufferbloat.net/~d/richb-hannover/richb-compare.svg
> 
> So not doing 4 up and down at the same time gives you latency results
> at max that are quite a bit
> larger than a single flow (which makes sense for tcp without
> congestion avoidance working)

	I wonder whether the single test flow leaves some bandwidth on the floor which then is used to accommodate the ping packets, or put differently the single uni-directional flow does not fully saturate the link (I assume that tcp reno is the lower bound so the leftover bandwidth is less than 25% on average, but still there should be enough slack for the ping packets). SO maybe going for at least two strerams per direction would be good? (It might be possible to speed up the ping train and get more values that way...)
	

Best Regards
	Sebastian

> 
> and microscopic upload performance compared to what the upload along claims.
> 
> sqm settings
> 
> config queue 'ge00'
>    option interface 'ge00'
>    option script 'simplest.qos'
>    option linklayer 'none'
>    option enabled '1'
>    option download '30000'
>    option upload '4400'
>    option qdisc_advanced '1'
>    option ingress_ecn 'ECN'
>    option egress_ecn 'ECN'
>    option qdisc_really_really_advanced '1'
>    option iqdisc_opts 'target 5ms'
>    option eqdisc_opts 'target 5ms'
>    option qdisc 'nfq_codel'
> 
> 
> 
> 
> On Tue, Mar 25, 2014 at 8:16 AM, Rich Brown <richb.hanover@gmail.com> wrote:
>> I have created a 'speedtest.sh' shell script that simulates the http://speedtest.net, but does it one better.
>> 
>> The default options for the script do a separate TCP_MAERTS and TCP_STREAM for 60 seconds while collecting ping latency. The output of the script shows the down/upload speed as well as a summary of the ping latency, including min, max, average, median, and 10th and 90th percentiles.
>> 
>> The script makes it easier to optimize my settings because it makes the latency figures more concrete. (I used to eyeball the ping output, saying, "Hmmm. I think there were fewer outliers than before...")
>> 
>> You can see the script on the "Quick Test for Bufferbloat" page on the wiki at:
>> 
>> http://www.bufferbloat.net/projects/cerowrt/wiki/Quick_Test_for_Bufferbloat#Speedtestsh-shell-script
>> 
>> Enjoy!
>> 
>> 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

Re: [Cerowrt-devel] speedtest.sh script available

[Aaron Wood]

[-- Attachment #1: Type: text/plain, Size: 3070 bytes --]

That was, in fact, to Toke's server, not to Rich's (and pings were to
google dns).

-Aaron

On Tue, Mar 25, 2014 at 6:13 PM, Dave Taht <dave.taht@gmail.com> wrote:

> aaron: tcp is highly sensitive to RTT and I imagine the rtt from paris
> to his server is rather high. See
> what happens via demo.tohojo.dk which is much closer to you.
>
> (ping times between there and rich's server would be good to have)
>
>
>
> On Tue, Mar 25, 2014 at 9:09 AM, Aaron Wood <woody77@gmail.com> wrote:
> > Nice!  It gives me what I'd expect for my setup, although the TCP rate is
> > only 2/3 the line rate on DSL (upload is better at 80%).
> >
> > ..............................................................
> >  Download:  14.09 Mbps
> >   Latency: (in msec, 62 pings, 0.00% packet loss)
> >       Min: 30.157
> >     10pct: 30.691
> >    Median: 33.412
> >       Avg: 34.044
> >     90pct: 36.970
> >       Max: 48.250
> > ..............................................................
> >    Upload:  0.87 Mbps
> >   Latency: (in msec, 57 pings, 8.06% packet loss)
> >       Min: 30.655
> >     10pct: 30.744
> >    Median: 36.658
> >       Avg: 36.379
> >     90pct: 41.414
> >       Max: 46.451
> >
> > I'm running 21000/1100 as my rate-limiting settings in CeroWRT
> (3.10.32-12).
> >
> > That packet loss is what kills my UDP ping streams.  It doesn't seem to
> > happen if I use the Free.fr box directly, and only shows when I use
> CeroWRT
> > as the bottle-neck.
> >
> > -Aaron
> >
> >
> > On Tue, Mar 25, 2014 at 4:16 PM, Rich Brown <richb.hanover@gmail.com>
> wrote:
> >>
> >> I have created a 'speedtest.sh' shell script that simulates the
> >> http://speedtest.net, but does it one better.
> >>
> >> The default options for the script do a separate TCP_MAERTS and
> TCP_STREAM
> >> for 60 seconds while collecting ping latency. The output of the script
> shows
> >> the down/upload speed as well as a summary of the ping latency,
> including
> >> min, max, average, median, and 10th and 90th percentiles.
> >>
> >> The script makes it easier to optimize my settings because it makes the
> >> latency figures more concrete. (I used to eyeball the ping output,
> saying,
> >> "Hmmm. I think there were fewer outliers than before...")
> >>
> >> You can see the script on the "Quick Test for Bufferbloat" page on the
> >> wiki at:
> >>
> >>
> >>
> http://www.bufferbloat.net/projects/cerowrt/wiki/Quick_Test_for_Bufferbloat#Speedtestsh-shell-script
> >>
> >> Enjoy!
> >>
> >> Rich
> >> _______________________________________________
> >> Cerowrt-devel mailing list
> >> Cerowrt-devel@lists.bufferbloat.net
> >> https://lists.bufferbloat.net/listinfo/cerowrt-devel
> >
> >
> >
> > _______________________________________________
> > 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
>

[-- Attachment #2: Type: text/html, Size: 4751 bytes --]

[Cerowrt-devel] betterspeedtest.sh (was: speedtest.sh script available)

[Rich Brown]

You can get it from my CeroWrtScripts git repo: https://github.com/richb-hanover/CeroWrtScripts It also includes the config-cerowrt.sh that I use to get consistent settings after flashing firmware, and my tunnelbroker.sh script that sets up a 6in4 tunnel.

On Mar 25, 2014, at 12:35 PM, Dave Taht <dave.taht@gmail.com> wrote:

> I suggest renaming it to something like bloattest, to avoid copyright
> and trademark issues. If you can come up with a sexier name,
> goferit... (I have had a name in hiding for a while, "lul" - latency
> under load,
> you are welcome to it)

For version 1.0, I'm going with "betterspeedtest.sh"? There are a bunch of "speedtest.sh" scripts out there. This one's better. (I never said I was good at names.  :-)

> ahh... my old friend... awk...

I don't know why it took me so long to learn about awk. What a hoot!

> If you change the script to use /bin/sh it works directly on cero!

Done.

> I have longed to have some sort of sane test server infrastructure in
> place, tied to a domain that did geographic dns, for a long time. Are
> you going to incur any costs in doing this? community driven and
> ad-supported seems like a way to go except that shell scripts don't
> have ads...

I'm happy to support this for the time being. This is currently running on a fairly studly VPS in Atlanta that costs $10/month. An individual netperf session doesn't bother it at all; we've had ~250 sessions since I mentioned this, and it hasn't even dented my bandwidth cap (<< 1%) I'm teaching myself node.js, so there'll shortly be a web page there that lets you see how many sessions and what CPU utilization it causes.

> I'd argue in favor of throwing out the first 25 sec of the test if you
> aren't already due to speedboost.

Interesting... Version 1.1

Rich