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

[Sebastian Moeller <moeller0@gmx.de>]

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