[Cerowrt-devel] trivial 6in4 fix(?)

Tue Jul 9 11:06:54 EDT 2013

Hi Toke, hi list

Here is more on the topic of (potential) ATM quantization on a DSL link. (Note ATM typically is used for all/most ADSL1/DASL2/ADSL2+ links and might also be used with VDSL links, even though for VDSL non-cell quantized packet transfer mode (PTM) hopefully is more likely).
Anyway, so here is what I use to collect ping times to test for ATM quantization. Just replace TARGET with the nearest IP on the other side of your DSL link that returns ping packets with low variation. The only potentially clever twist here is to call ping for each packet independently and sleep for a tiny bit in-between to allow non-root to ping rates > 1Hz (based on sleep accepting non-integer inputs). (It is worth mentioning that in my tests to high frequencies to the same host led to very long ping RTTs, as if the host was putting my requests into a slow path, so for each host it might be required to titrate the lowest period to still get typical ping responses...)
I typically would let this run overnight, at 0.01 seconds PINGPERIOD period this will take 10100seconds or ~168 minutes. For my ADSL2+ link at 2558kbit uplink and 16402kbit downlink the numbers below give a very noticeable quantization step, for higher link speeds one might need to increase PINGSPERSIZE… Now, I have some reworked matlab code to parse and display the data from the ping log file, that also will attempt to estimate the ATM encapsulation related overhead on an ATM link; let me know whether there is any interest for that…

best
	sebastian

#! /bin/bash
# TODO use seq or bash to generate a list of the requested sizes (to alow for non-equdistantly spaced sizes)

# Telekom Tuebingen Moltkestrasse 6
TECH=ADSL2
# 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
TARGET=87.186.197.70		# T
DATESTR=`date +%Y%m%d_%H%M%S`	# to allow multiple sequential records
LOG=ping_sweep_${TECH}_${DATESTR}.txt

# 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)
PINGPERIOD=0.01		# in seconds
PINGSPERSIZE=10000

# Start, needed to find the per packet overhead dependent on the ATM encapsulation
# to reiably show ATM quantization one would like to see at least two steps, so cover a range > 2 ATM cells (so > 96 bytes)
SWEEPMINSIZE=16		# 64bit systems seem to require 16 bytes of payload to include a timestamp...
SWEEPMAXSIZE=116

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)

On Jun 17, 2013, at 12:50 , Toke Høiland-Jørgensen <toke at toke.dk> wrote:

> Sebastian Moeller <moeller0 at gmx.de> writes:
> 
>> I fully believe you that it is flat (graph did not make it into my
>> inbox…)
> 
> Heh. May have forgotten to attach it... Should be there now...
> 
>> So that looks like PTM. Good! But beware the expected step size
>> depends on your down and uplink speeds, at VDSL I would only expect a
>> very tiny increase (basically the time it takes to see an additional
>> ATM cell back and forth, (RTT step per ATM cell in milliseconds =
>> (53*8 / line.down.bit + 53*8 / line.up.bit ) * 1000); this means that
>> potentially a large sample size per ping packet size is required to be
>> reasonably sure that there is no step....
> 
> Right, well in my case that comes out as something like 0.05 ms, which
> is way below the measuring accuracy of my ping test (lowest mdev as
> reported by ping is 0.7ms; highest is 3.3). So I guess testing is not
> really going to be viable in this case. But then perhaps it's not going
> to make much of a difference either way in this case?
> 
>> Hence in theory using a saturating load and measuring the latencies
>> for different overhead values should still work. I wonder whether rrul
>> might just be the right probe? If you go that route I would be
>> delighted to learn the outcome :). Sorry to be of no more help here.
> 
> Right. That seems reasonable. However, it also seems to require a bit
> more testing than I really have the time to spare right now, so I think
> I'll defer it for the time being. I wonder if it would be possible to
> persuade my ISP to set up a netperf server to test against...
> 
> Either way, thanks for your insight; I'll be sure to ping you if I come
> up with something more conclusive... :)
> 
> -Toke
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/cerowrt-devel/attachments/20130709/161fe3d7/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pings.png
Type: image/png
Size: 10733 bytes
Desc: not available
URL: <https://lists.bufferbloat.net/pipermail/cerowrt-devel/attachments/20130709/161fe3d7/attachment-0002.png>