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.