Hi Toke,
On Jun 17, 2013, at 11:44 , Toke Høiland-Jørgensen <t...@toke.dk> wrote:
> Sebastian Moeller <moell...@gmx.de> writes:
>
>> Honestly, I think the best thing to do is not so much assume ATM or
>> lack of ATM, but simply measure it :)
>
> Right, doing the ping test with payload sizes from 16 to 113 packets
> gives me an almost completely flat ping time distribution ranging from
> 20.3 to 21.3 ms (see attached graphic). So probably I'm on PTM…
I fully believe you that it is flat (graph did not make it into my
inbox…) 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....
>
>> Easy to figure out empirically by hand, by finding the largest ping
>> packet size that still passes without fragmentation (see
>> http://www.debian.org/doc/manuals/debian-reference/ch05.en.html#_finding_optimal_mtu)
>
> $ ping -c 1 -s $((1500-28)) -M do www.debian.org
> PING www.debian.org (128.31.0.51) 1472(1500) bytes of data.
> 1480 bytes from senfl.debian.org (128.31.0.51): icmp_seq=1 ttl=45 time=114 ms
>
> --- www.debian.org ping statistics ---
> 1 packets transmitted, 1 received, 0% packet loss, time 0ms
> rtt min/avg/max/mdev = 114.522/114.522/114.522/0.000 ms
>
> $ ping -c 1 -s $((1500-27)) -M do www.debian.org
> PING www.debian.org (128.31.0.51) 1473(1501) bytes of data.
> From 10.42.3.5 icmp_seq=1 Frag needed and DF set (mtu = 1500)
>
> --- www.debian.org ping statistics ---
> 0 packets transmitted, 0 received, +1 errors
>
> So the MTU seems to be 1500 bytes.
That is great!
>
> Now, how do I figure out what the PTM overhead is and feed it to HTB? :)
All I know so far is that PTM will not drag in the quite baroque ATM
encapsulation options. Googling for vdsl2 makes me hope that maybe there is no
additional user visible overhead; so if you have PPP that would still need
handling. It would be quite interesting to determine the overhead empirically.
ATM's quantization makes overhead detection in atm based del lines conceptually
easy; but for VDSL I am not so sure. In principle we expect to see "buffer
bloat" and its signature increase of latency on saturated links if we shape
with too high rates. So too small an overhead should fill the modems buffers
and might increase latency (depending on the modems configuration, but assuming
pfifo the buffer should just fill up slowly until latencies should be
noticeably affected, or?). 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.
Best
Sebastian
>
> -Toke
_______________________________________________
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel
