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-AES256-SHA (256/256 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-1" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 438CA21F543 for ; Fri, 21 Nov 2014 04:14:18 -0800 (PST) Received: from u-100-d033.biologie.uni-tuebingen.de ([134.2.100.33]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0MeP5b-1XaXlI3UjP-00QF0M; Fri, 21 Nov 2014 13:14:15 +0100 Content-Type: multipart/mixed; boundary="Apple-Mail=_651A051C-F50E-4C4F-BABE-EE910B2E1560" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sebastian Moeller In-Reply-To: Date: Fri, 21 Nov 2014 13:14:14 +0100 Message-Id: References: <0A4731BD-C9C0-4CA3-8147-C65CFF291741@gmx.de> To: Dane Medic X-Mailer: Apple Mail (2.1878.6) X-Provags-ID: V03:K0:Gwpk1QvsgoOsyiKv59L6tHWCHQ4C2YqEZKuTcI1J/yeU4ZbdnCg igjSFnHcEJRbCZBWZpHrSh4RLy7OG/TlU5xN5lDD16nZ5rC0uYxFYP+UwURvR/0n9fpldCQ 9ISxbIf+wRYMiT9HlwnbLmPTE14Nst93Jy0VDOt5jPrgY+d+aKcBLShhAGXXFxBgOhKNhNg KCbzP5abXP3pn1c6UCL/g== X-UI-Out-Filterresults: notjunk:1; Cc: "cerowrt-devel@lists.bufferbloat.net" Subject: Re: [Cerowrt-devel] Torrents are too fast 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: Fri, 21 Nov 2014 12:14:47 -0000 --Apple-Mail=_651A051C-F50E-4C4F-BABE-EE910B2E1560 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Dane, On Nov 21, 2014, at 12:51 , Dane Medic wrote: > Hi, >=20 > correct, I've left egress on 4000 (I thought I should test only = ingress first), A reasonable approach, I just predict that it will only work = well once you have shapers on bothe ingress and egress configured = correctly. > but when I did the test with youtube + torrent transfer, I've had set = upload to very small number (I think 10 kbytes/s). I am confused, you restricted the egress speed to 10 Kbps and = wonder why performance was less than satisfactory? :) I you just want to = be sure that you are not limited by bloated buffers restricting the = bandwidth to 50% of link rates (or even rougher of the transfer estates = of betterspeedtest.sh) should be a good starting point. At that rate you = will only be able to send 6.66666666667 full sized packets per second = each taking 150 ms. >=20 > Yes I have DSL line (VDSL2 as I've read ISP info), Hard to believe that any ISP will give you VDSL2 at around = 4M/512K as at that speed you are either so far away from the DSLAM that = VDSL2 is not any better than ADSL, probably worse, or you link is faster = and your ISP throttles your bandwidth due to contract. But you could run = the attached script overnight from a linux or macosx machine to test = whether your link used ATM encapsulation. A link using ATM will really = improve by specifying the correct link layer adjustments and overhead, = VDSL2 not so much. If you run this script I am happy to help you analyze = it to figure out whether your link uses ATM or not. Oh by the way most = ISP modems/routers have a web page that offers (technical) information = about the link it would be great if you could find and post that. --Apple-Mail=_651A051C-F50E-4C4F-BABE-EE910B2E1560 Content-Disposition: attachment; filename=ping_sweeper7.sh Content-Type: application/octet-stream; name="ping_sweeper7.sh" Content-Transfer-Encoding: 7bit #! /bin/bash # TODO use seq or bash to generate a list of the requested sizes (to alow for non-equdistantly spaced sizes) # just an identifier for the ping log TECH=ADSL # finding a proper target IP is somewhat of an art, just traceroute a remote site # and find the nearest host reliably responding to pings showing the smallet variation of pingtimes # for this I typically run "traceroute 8.8.8.8", and then select the first host on the ISP side (typically after # the first large RTT increment) and test its response by "ping -c 10 -s 16 NNN.NNN.NNN.NNN", if this host does not repsond # I pick the next host along the route to 8.8.8.8. I assume the closer the host the less disturbed by other traffic the # response will be. if [ ! $# == 1 ]; then echo "To run measurements supply the TARGET IP address as first agument to ${0} this script." echo "Use traceroute 8.8.8.8 to get a list of increasingly distant hosts, pick the first host out of your network (ideally the DSLAM)." echo "Test whether the selected host responds to ping: 'ping -s16 -c 1 target.IP.address.quad' : this needs to actually return non zero RTTs." echo "If the hosts does not reply to the pings take the next host from the traceroute (movin closer to 8.8.8.8), repeat until you find a replying host." echo "Once the main script is started have a quick look at the logfile, to see whether the RTTs stay close to the initial test RTT." echo "If the RTTs have increased a lot, the PINGPERIOD might be too short, and the host might have put us on a slow path; either increase PINGPERIOD or try the next host..." echo "" echo "Here is the traceroute (might take a while):" echo "" traceroute 8.8.8.8 echo "" echo "Alternatively you might try to use googles infrastructure by running: ${0} gstatic.com " exit 0 else TARGET=${1} # Replace by an appropriate host fi DATESTR=`date +%Y%m%d_%H%M%S` # to allow multiple sequential records LOG=ping_sweep_${TECH}_${DATESTR}.txt MAX_PREIP_OVERHEAD_SIZE=44 # as far as I can tell 44 bytes is the maximum pre IP header overhead for an ATM based carrier IP4_HEADER_SIZE=20 # 20 bytes IDEAL_MTU=1500 # what the MTU should look like # by default non-root ping will only end one packet per second, so work around that by calling ping independently for each package # empirically figure out the shortest period still giving the standard ping time (to avoid being slow-pathed by our host) # at 100 packets/s of 116 + 28 + 40 we would need 4 ATM cells = 192byte * 100/s = 150kbit/s # at 100 packets/s of 16 + 28 + 40nwe would need 2 ATM cells = 96byte * 100/s = 75kbit/s # on average we need 150 + 75 * 0.5 = 112.5 Kbit/s, increase the ping period if uplinh < 112.5 Kbit/s PINGPERIOD=0.01 # reduce if uplink slower than roughly 200Kbit/s PINGSPERSIZE=10000 # the higher the link rate the more samples we need to reliably detect the increasingly smaller ATM quantisation steps. Can be reduced for slower links # Start, needed to find the per packet overhead dependent on the ATM encapsulation # to reliably show ATM quantization one would like to see at least two steps, so cover a range > 2 ATM cells (so > 96 bytes) # Note to be more robust use 3 SWEEPMINSIZE=16 # 64bit systems seem to require 16 bytes of payload to include a timestamp... SWEEPMAXSIZE=116 SWEEPMAXSIZE=166 # this contains 3 full cells so more transitions to pin the quantization offset to... n_SWEEPS=`expr ${SWEEPMAXSIZE} - ${SWEEPMINSIZE}` i_sweep=0 i_size=0 while [ ${i_sweep} -lt ${PINGSPERSIZE} ] do (( i_sweep++ )) echo "Current iteration: ${i_sweep}" # now loop from sweepmin to sweepmax i_size=${SWEEPMINSIZE} while [ ${i_size} -le ${SWEEPMAXSIZE} ] do echo "${i_sweep}. repetition of ping size ${i_size}" ping -c 1 -s ${i_size} ${TARGET} >> ${LOG} & (( i_size++ )) # we need a sleep binary that allows non integer times (GNU sleep is fine as is sleep of macosx 10.8.4) sleep ${PINGPERIOD} done done #tail -f ${LOG} echo "Done... ($0) " --Apple-Mail=_651A051C-F50E-4C4F-BABE-EE910B2E1560 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 > I'll try to set the linklayer option on ethernet with overhead of 8, = like it says on = http://www.bufferbloat.net/projects/cerowrt/wiki/Setting_up_SQM_for_CeroWr= t_310 > I have linux machine so I'll install netperf-wrapper and test things If you really have a VDSL2 link the overhead will not make much = of a difference. Best Regards Sebastian >=20 > sqm configuration: >=20 > root@cerowrt:~# uci show sqm > sqm.ge00=3Dqueue > sqm.ge00.interface=3Dge00 > sqm.ge00.qdisc=3Dfq_codel > sqm.ge00.script=3Dsimple.qos > sqm.ge00.qdisc_advanced=3D1 > sqm.ge00.ingress_ecn=3DECN > sqm.ge00.egress_ecn=3DNOECN > sqm.ge00.qdisc_really_really_advanced=3D1 > sqm.ge00.itarget=3Dauto > sqm.ge00.etarget=3Dauto > sqm.ge00.linklayer=3Dnone > sqm.ge00.download=3D3100 > sqm.ge00.upload=3D4000 You should probably set this to 480 or 400 to be on the save = side, for you initial tests (judged from the speed tests) and later try = to see how far up you can push this without destroying latency under = load... > sqm.ge00.enabled=3D1 >=20 > Thank you guys, > Dane >=20 > 2014-11-21 12:16 GMT+01:00 Sebastian Moeller : > Hi Dane, >=20 >=20 > On Nov 20, 2014, at 15:13 , Dane Medic wrote: >=20 > > dpreed, thank you for response. I'm already using fq_codel with = cerowrt and I don't think it does what I want (or maybe I want too much = :) > > > > So the steps I've made: > > flashed wndr3700v2 with cerowrt 3.10.50-1 then I've measured: > > > > root@cerowrt:/usr/lib/CeroWrtScripts# sh betterspeedtest.sh -p = wlan-si.net -t 120 > > 2014-11-20 12:18:34 Testing against netperf.bufferbloat.net (ipv4) = with 5 simultaneous sessions while pinging wlan-si.net (120 seconds in = each direction) > > = ..........................................................................= ............................................... > > Download: 3.78 Mbps > > Latency: (in msec, 119 pings, 0.00% packet loss) > > Min: 13.077 > > 10pct: 251.522 > > Median: 317.851 > > Avg: 308.497 > > 90pct: 371.033 > > Max: 376.132 > > = ..........................................................................= .................................................. > > Upload: 0.48 Mbps > > Latency: (in msec, 103 pings, 0.00% packet loss) > > Min: 12.278 > > 10pct: 12.727 > > Median: 18.359 > > Avg: 23.256 > > 90pct: 33.971 > > Max: 180.303 > > > > Then I've put these commands: > > > > uci set sqm.ge00.enabled=3D1 > > uci set sqm.ge00.download=3D3200 > > uci set sqm.ge00.qdisc=3Dnfq_codel > > uci commit sqm > > reboot > > > > And another measure: > > > > root@cerowrt:/usr/lib/CeroWrtScripts# sh betterspeedtest.sh -p = wlan-si.net -t 120 > > 2014-11-20 12:49:05 Testing against netperf.bufferbloat.net (ipv4) = with 5 simultaneous sessions while pinging wlan-si.net (120 seconds in = each direction) > > = ..........................................................................= ............................................... > > Download: 2.74 Mbps > > Latency: (in msec, 121 pings, 0.00% packet loss) > > Min: 12.210 > > 10pct: 13.002 > > Median: 15.077 > > Avg: 15.095 > > 90pct: 16.968 > > Max: 18.599 > > = ..........................................................................= ................................................... > > Upload: 0.49 Mbps > > Latency: (in msec, 101 pings, 0.00% packet loss) > > Min: 12.255 > > 10pct: 12.684 > > Median: 16.679 > > Avg: 23.100 > > 90pct: 34.019 > > Max: 170.173 > > > > The tests doesn't look bad, but the problem is I watch a video clip = on youtube and my sister starts torrent client, I can't watch anymore. >=20 > Could you post the content of /etc/config/sqm from after = activating SQM please. It looks like you did not activate shaping on = egress (its not in the =93ici set *=94 above and the upload statistics = look identical to the first unshaped example). You really need to = control the buffer in both directions to get rid of nasty latency spikes = (especially with torrents that I assume will try to use both directions = maximally if left to their own devices). Also 4M/512K sounds like a DSL = link, if so you might find the link layer adjustments helpful (if there = are question what to fill in just ask). Also if you have a linux or = macosx computer available I would recommend to install netperf-wrapper = and use the RRUL test to simultaneously load down- and up-link (or = alternatively netperfrunner.sh) as this will show bloated buffers more = clearly than the individual tests for each direction as performed by = betterspeedtest.sh. >=20 > Best Regards > Sebastian >=20 >=20 > > > > Cheers > > _______________________________________________ > > Cerowrt-devel mailing list > > Cerowrt-devel@lists.bufferbloat.net > > https://lists.bufferbloat.net/listinfo/cerowrt-devel >=20 >=20 --Apple-Mail=_651A051C-F50E-4C4F-BABE-EE910B2E1560--