On Jun 17, 2013, at 12:50 , Toke Høiland-Jørgensen <toke@toke.dk> wrote:
Sebastian Moeller <moeller0@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