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

[Sebastian Moeller]

Hi Toke,


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…

	It is… I agree no noticeable stepping (btw. in theory taking the minimum at each ping size would be more precise, in practice for ATM the median seems to work best). The min because that is limited by wire speed and optimal processing, the median as it turned out to be less noisy...

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

	I tend to agree, if interpreted as a statistical power problem at stddev 0.7, around 1000 samples should do fine (power of 72% for detecting an effect of 0.05), but at 3.3 even 20500 samples per size will only give you 70% power. To save some time the ATM quantization test can be reduced to 3 sizes: say 16 (seems to be the smallest ping size( on 64 bit systems?) that allows timestamps), 16+24 and 16+48; out of these 3 two are guaranteed to require the same number of ATM cells the other one will be either one small or one bigger. But at n ~20k this still takes too long :)

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

	Nah it still is, as ATM will pad the unused reminder of the last cell of each packet, for small packets that will mean a considerable amount of your bandwidth is wasted on padding. On average you are going to waste half a cell, naively speaking; and for small packets that can easily be above 33%. And if you do not regard that into your shaping you will run into issues for a flood of small packets, namely you are not shaping enough and your modem will fill its buffers… Thinking of this, another war to test for ATM carrier is to shape to the nominal link speeds and see whether flooding some upstream with minimally small packets affects latency. But unlike the step method this will not give you the satisfaction of seeing the quantization in a decent plot...

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

	Well, if you talk to your ISP you could also ask them for ATM or PTM and any potential overhead :)

> 
> Either way, thanks for your insight; I'll be sure to ping you if I come
> up with something more conclusive... :)

	Great and thanks
Best
	Sebastian

> 
> -Toke
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/cerowrt-devel/attachments/20130617/c1fd16e9/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/20130617/c1fd16e9/attachment-0002.png>