Re: [Cerowrt-devel] Torrents are too fast

[Sebastian Moeller <moeller0@gmx.de>]

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

Hi Dane,

On Nov 21, 2014, at 12:51 , Dane Medic <dm70dm@gmail.com> wrote:

> Hi,
> 
> 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.

> 
> 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.

[-- Attachment #2: ping_sweeper7.sh --]
[-- Type: application/octet-stream, Size: 4042 bytes --]

#! /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)
"

[-- Attachment #3: Type: text/plain, Size: 4921 bytes --]




> 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_CeroWrt_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

> 
> sqm configuration:
> 
> root@cerowrt:~# uci show sqm
> sqm.ge00=queue
> sqm.ge00.interface=ge00
> sqm.ge00.qdisc=fq_codel
> sqm.ge00.script=simple.qos
> sqm.ge00.qdisc_advanced=1
> sqm.ge00.ingress_ecn=ECN
> sqm.ge00.egress_ecn=NOECN
> sqm.ge00.qdisc_really_really_advanced=1
> sqm.ge00.itarget=auto
> sqm.ge00.etarget=auto
> sqm.ge00.linklayer=none
> sqm.ge00.download=3100
> sqm.ge00.upload=4000

	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=1
> 
> Thank you guys,
> Dane
> 
> 2014-11-21 12:16 GMT+01:00 Sebastian Moeller <moeller0@gmx.de>:
> Hi Dane,
> 
> 
> On Nov 20, 2014, at 15:13 , Dane Medic <dm70dm@gmail.com> wrote:
> 
> > 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=1
> > uci set sqm.ge00.download=3200
> > uci set sqm.ge00.qdisc=nfq_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.
> 
>         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 “ici set *” 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.
> 
> Best Regards
>         Sebastian
> 
> 
> >
> > Cheers
> > _______________________________________________
> > Cerowrt-devel mailing list
> > Cerowrt-devel@lists.bufferbloat.net
> > https://lists.bufferbloat.net/listinfo/cerowrt-devel
> 
>