From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-1" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 20D3F21F1F4 for ; Tue, 25 Mar 2014 10:58:34 -0700 (PDT) Received: from u-089-cab204a2.am1.uni-tuebingen.de ([134.2.89.3]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0M8edX-1XEzJ73Jdj-00wDfd; Tue, 25 Mar 2014 18:58:30 +0100 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Sebastian Moeller In-Reply-To: Date: Tue, 25 Mar 2014 18:58:29 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <2DF8C442-A21C-4A4C-A6C4-BFDD851389A0@gmx.de> References: <171F2F69-A85F-440B-8126-E9813D1EEEF0@gmail.com> To: Dave Taht X-Mailer: Apple Mail (2.1510) X-Provags-ID: V03:K0:tsmH+UJe5/x9i+XTJHq+lANXX5VeIReNg8Kpj+l9rGnB3EMeqNi wT0WknBs5eZ8WEHhYzsJFNAGm+Dec1o9Kh4e/oPjjSsN/pSz8zXtLKSTUliFWYQG4X5E+rP aH9JxEH+FWj1squZLUQv3+MYzlT7PLSZfVkk1Zts4SNohpWzx7OYVUEr0a1y+tCj8w10SEC s0MWelo8cfT1X/1POUnFQ== Cc: cerowrt-devel Subject: Re: [Cerowrt-devel] speedtest.sh script available X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Mar 2014 17:58:34 -0000 Hi List, On Mar 25, 2014, at 17:35 , Dave Taht 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) >=20 > ahh... my old friend... awk... >=20 > If you change the script to use /bin/sh it works directly on cero! >=20 > 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... >=20 > I'd argue in favor of throwing out the first 25 sec of the test if you > aren't already due to speedboost. >=20 > 1) This is a box connected directly to the internet: >=20 > 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 >=20 > 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 =3D 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 =3D 113.298/113.458/113.933/0.173 ms >=20 > 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=3D1 > ttl=3D59 time=3D0.924 ms > 64 bytes from nuq05s02-in-f15.1e100.net (74.125.239.143): icmp_req=3D2 > ttl=3D59 time=3D0.915 ms >=20 > 2) Run from my nuc >=20 > 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 >=20 > I then tried the armory's comcast connection... >=20 > 3) Run from cero >=20 > 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 >=20 > So we still have some variance in calculating up/download speeds... >=20 > 4) Run from cero with sqm off: >=20 > root@comcast-gw:~# ./speedtest.sh > Testing against netperf.richb-hanover.com while pinging gstatic.com > (60 seconds in each direction) > ............................................................. > Download: 28.1 Mbps >=20 > +the sqm system is set to 30000 down >=20 > 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 >=20 > 5) for comparison, a rrul test is at > http://snapon.lab.bufferbloat.net/~d/richb-hannover/richb-compare.svg >=20 > 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...) =09 Best Regards Sebastian >=20 > and microscopic upload performance compared to what the upload along = claims. >=20 > sqm settings >=20 > 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' >=20 >=20 >=20 >=20 > On Tue, Mar 25, 2014 at 8:16 AM, Rich Brown = wrote: >> I have created a 'speedtest.sh' shell script that simulates the = http://speedtest.net, but does it one better. >>=20 >> 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. >>=20 >> 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...") >>=20 >> You can see the script on the "Quick Test for Bufferbloat" page on = the wiki at: >>=20 >> = http://www.bufferbloat.net/projects/cerowrt/wiki/Quick_Test_for_Bufferbloa= t#Speedtestsh-shell-script >>=20 >> Enjoy! >>=20 >> Rich >> _______________________________________________ >> Cerowrt-devel mailing list >> Cerowrt-devel@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/cerowrt-devel >=20 >=20 >=20 > --=20 > Dave T=E4ht >=20 > 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