Find out correct per packet overhead for sqm

Hi, i was wondering how to find out the correct the packet overhead for sqm.

I'm running openwrt on a linksys ea8300 behind a fritzbox 7412 from my internet provider. The fritzbox is configured as the gateway on my linksys. The internet connection on the fritzbox is done by VDSL2 17a G.Vector (ITU G.993.5).

Is there a diagnostics tool i can use or something similar?

First hit on the wiki:

1 Like

Honestly? Ask your ISP ;). The point is we can deduce quite a lot about the likely overhead, but on most DSL links the relevant limit is not the actual DSL link but a traffic shaper on the ISP side. If that is competently configured the overhead the shaper accounts for >= the true overhead on the link, and it is mostly the max(overhead_shaper, overhead_DSL-link) that we need to find out and account for.

But fear not, from a "bufferbloat" perspective it is sufficient to set the shaper overhead >= true overhead, = is harder that mildly >, so something like 34 bytes or to be on the safe safe 40 should be decent starting values... the OpenWrt Details wiki has a section on the overhead accounting that you might want to read...

When I was on DSL, 40 worked well for a 6 down/1 up connection.

For most ADSL links (namely those that use ATM/AAL5 and not PTM) we have a reasonably successful/efficient way to empirically deduce the actual per-packet overhead... and yes 40 often is a correct answer :wink:

@moeller0 thank you for the great answers!

The ADSL script would not work on VDSL2, or would it?

I'm not that deep into WAN techologies and i was curious if it makes a difference for packet overhead if openwrt is running on the modem device directly or it openwrt is behind another device that does the internet connect.

I will set it on 40 now, because i can't find any informations from my ISP (1&1 - A german ISP) about it. I know only that its VDSL2 with profil 17a.

I would use VDSL2 for a VDSL2 connection.

VDSL delivers faster connection speed than ADSL.

Unlikely, the thing is that method uses a peculiarity of ATM/AAL5 encapsulation (where on the wire size increases by a step function, since each packet is always split into an integer number of ATM cells and individual cells only ever carry data for one ethernet/IP frame), and while the standards do allow using ATM/AAL5 on an VDSL2 link, I have never seen reports of such a beast, all links I have seen data of use PTM instead, which honestly is the better choice, in every dimension except the compatibility with the ATM overhead detector.... So in theory it might work with VDSL2, but in practice that is very unlikely.

Not really, for a traffic shaper to reliably keep bufferbloat controlled it needs to "account for" the properties of the true bottleneck link and since that is not really dependent on where the shaper itself lives, the shaper settings will not differ (much, there are special cases when things might change)

But since veridical bottleneck information is hard to come by, so the recommendation is to set:
shaper gross rate: <= true bottleneck gross rate
per-packet overhead: >= true bottleneck per-packet overhead

That will err on the side of trading in a little tthroughput for reliable low latency under load increases.

In that case 34bytes might be the correct number (PTM,VLAN7,PPPoE), but since 40 >= 34, just leave it at 40 and don't bother... That way, you are likely save even if your ISP should increase its overhead a little.

please forgive me for resurecting an old thread. One thing I cannot fully understand is this - what is the point from which we are counting the overhead? Are we counting the various header bytes that are below the IPv4: P-t-P Protocol, PPPoE Session, Ethernet frame headers? If yes, where (which OSI layer) does PTM fit? And to what extend can we see this with the help of tcpdump/Wireshark?

Thank you very much for guiding us all through this uneasy topic.

Typically on top of IPv4 or IPv6, but depending on the encapsulation there can be another IP header around the payload...

Yes, that is one way of seeing it inspired by OSI layers, I had caled these layers as being on-top of IP but the idea is the same :wink:

Not an expert on OSI layers, but probably mostly layer 2 arguably digging down a bit into layer 1, but as I said not an OSI expert...

Well, this depends what interfaces you have access to, but I believe that typically you only see the ethernet frame payload from a packet capture, but I have not tried that on a physical PTM interface yet... The challenge with overhead is that that overhead can be hard to actually measure, as it might only exist along a segment of the path that can not be probes easily (e.g. ATM, but I also never tried to capture from an ATM interface). So I guess, I really do not know, sorry.

1 Like