That is rather a rare situation, which ISP are you using?
How much does a couple of bytes really matter here. I'm thinking sure it's important to get close but unless you do a lot of small packet traffic, 5-10 bytes on top of 800-1500 byte traffic is a very small error. Even if you run say 2 VoIP calls and a game, you're talking less than a megabit of traffic, on modern connections that are 5-10 Mbps up at least again a small fraction of your traffic, so a 10% size error on a quantity that is 10% of packet size on traffic that is 10% of your bandwidth...
It might be best to just say 46 bytes and be done with it 
the difference between even 30 and 60 is probably negligible to anyone not running a regression on a couple megabytes of data.
About the only people who should consider more precision is a call center running hundreds of VoIP calls on a dedicated line.
Deutsche Telekom
Well, I was under the impression, by reading the SQM docs, that getting this value "right" is essential for the proper functioning of Cake. "Right" may mean "Exactly right", i.e., not more, not less.
I guess what I'm arguing is that exactly right is not needed, within 10% of the right value is probably just fine for all but a VOIP call center running hundreds of calls on a tight 10-15Mbps symmetric line.
The reason it's needed is to calculate the true packet size. If packet payload size is 1500 bytes then +-45 bytes makes only ~3% error. If packet size is 150 bytes like in a VoIP call, then 45 bytes is 33% error! So having the overhead included is important, but the difference between overhead say 44 and overhead 48 is 4 bytes and 4 bytes on 150 bytes is now back to 3% error so, do you know the capacity of your line to within 3% error? If not then even if you're a VoIP call center the error in your overhead if you just say 44 bytes is offset by the fact you aren't sure if you should put 10000 kbps or 9700kbps... If you're not a call center it's even an order of magnitude less important...
I can guarantee that you just have plain PPPoE, otherwise the detected overhead would be different and DTAG only uses PPPoE 
1 Like
@moeller0 would it be possible to edit the wiki section on link layer adaptation to reflect the not too tight tolerances for most everyday purposes.
I agree that accounting for overhead is important, but I'm guessing we could add a section saying "Most people can just put 44 and it will work for you regardless of what your underlying technology is. For some people with fiber or cable connections, this may waste up to around 1-2% of your bandwidth, but it will bias you towards having lower bufferbloat rather than higher which is usually a good thing. The primary use case for more precise tuning is when your internet speed is relatively low (less than 5Mbps) and / or you have more than 20% of your internet speed in either direction taken up by small-packet traffic such as VOIP or gaming. If you have more than 5Mbps and/or you are not running a call center, further adjustment is probably not worth the effort and you should spend more time trying to better measure your reliable level of internet speed itself."
With that sort of preliminary warning, then we can still keep all the details for nerds like us but non-technical people will not feel like things are harder than they need to be.
Reading through the wiki, I'm seeing it's already intended to convey this kind of information, but maybe some rewording is in order to let people know more about what this stuff is supposed to be doing. I'm going to try to adjust it a little, feel free to revert my edits or further edit them if you disagree.
1 Like
ATM is tricky in regards to bufferbloat, if you specify too much overhead you just loose some bandwidth, if you specify too little you will occasionally get an additional unaccounte-for almost empty ATM cell, eating 53 bytes of your sync bandwidth, with small packet, say VoIP ~200Byte packets that could mean 25% under accounting of the actual on-the-wire size. So cake would believe that it admits 200 byte to the wire, but really admits 253, which is a sure-fire way to get hard to debug packet-backspill distribution dependent buffer lost on your link. The problem here really is AAL5's requirement that user frames are packaged into an integer number of ATM cells.
Yes, I definitely think the default recommendation should be to overestimate. Because of that I changed some of the wording on the wiki to recommend things slightly differently from what was there before. In particular for FTTP or metro Ethernet etc I said to choose ethernet with overhead and set 38 bytes. These connections tend to be fast, and the people reading the wiki are less likely to be doing call centers, so even if their actual overhead is 0, they will lose maybe 2.5 % bandwidth for large transfers, and they'll overestimate a 100kbps phone call by 15%, but 100kbps is less than 1% of a 10Mbps line, so unless they're running 10 simultaneous calls, again the "waste" is less than 1.5% for a typical metro E line, for a fiber at 100Mbps it's truly negligible unless they are running 1000 call simultaneous call center
Not 100% sure whether these are your changes already, but the sqm entry page has something close to what you propose already:
In the Link Layer Adaptation tab, choose the kind of link you have:
For VDSL - Choose Ethernet, and set per packet overhead to 22
For DSL of any other type - Choose ATM, and set per packet overhead to 44
For Cable or other kinds of connections - Choose Ethernet, and set per packet overhead to 18
For true ethernet - Choose Ethernet, and set per packet overhead to 38
Click Save & Apply. That's it!
This will take probly not much more time to read than the text to explain why it does not really matter that much... Although I guess we should add:
If in doubt set this to 44.
Here's the text from the details page with my edits, copied and pasted from: https://openwrt.org/docs/guide-user/network/traffic-shaping/sqm-details#sqmlink_layer_adaptation_tab
SQM: Link Layer Adaptation Tab
The purpose of Link Layer Adaptation is to give the shaper more knowledge about the actual size of the packets so it can calculate how long packets will take to send. When the upstream ISP technology adds overhead to the packet, we should try to account for it. This primarily makes a big difference for traffic using small packets, like VOIP or gaming traffic. If a packet is only 150 bytes and say 44 bytes are added to it, then the packet is 29% larger than expected and so the shaper will be under-estimating the bandwidth used if it doesn't know about this overhead.
Getting this value exactly right is less important than getting it close, and over-estimating by a few bytes is generally better at keeping bufferbloat down than underestimating. With this in mind, to get started, set the Link Layer Adaptation options based on your connection to the Internet. The general rule for selecting the Link Layer Adaption is:
- Choose ATM: select for e.g. ADSL1, ADSL2, ADSL2+ and set the Per-packet Overhead to 44 bytes if you use any kind of DSL/ADSL connection to the Internet (that is, if you get your internet service through a telephone line).
- Choose Ethernet with overhead: select for e.g. VDSL2 and set the Per-packet Overhead to 22 if you know you have a VDSL2 connection (this is sometimes called Fiber to the Cabinet, for example in the UK). If you have a cable modem, you can try 22 bytes, or see the Ethernet with Overhead details below.
- Choose Ethernet with overhead if you have an actual Fiber to the Premises or Ethernet connection and set the Per-Packet Overhead to 38 bytes.
- Choose none (default) if you have some reason to not include overhead. All the other parameters will be ignored.
If you are not sure what kind of link you have, first try using Ethernet with Overhead and set 38 bytes. Then run the Quick Test for Bufferbloat. If the results are good, you’re done. Next, try the ATM choice, then the VDSL choice to see which performs best. If you have a slow connection such as less than 2Mbps in either direction and/or you regularly use several VOIP calls at once while gaming etc (so that more than 10 to 20% of your bandwidth is small packets) then it can be worth it to tune the overhead more carefully, see below for details.
Perhaps we can hammer out a reconciliation between this text and the text on the sqm (non-details) page, and make sure they both say the same useful thing.
1 Like
I am not sure whether the details page will reach the intended audience 
as there is a less technical introduction page in the documentation. But sure most of what I can see on my phone seems an improvement, maybe with the exception of trying ATM as that will cost 9% bandwidth just for the 48/53 encapsulation, but I need to read it on a real screen first....
Thanks for taking the time to improve the documentation!
Edited the post to use blockquote, and added some enumerated list... should be easier to read now.
I'm going on the basis that our friend @deuteragenie was pointing to this documentation so someone like that will wind up here and I wanted them to get a holistic impression.
I figure based on reading the details that it's safe to overestimate the overhead on cable at 22. I think this is the only real discrepancy between what I put and what is on the simpler page. So I edited the simpler page to put 22 there, and to add a "when in doubt it's safe to overestimate, use 44" item
A couple of years back you helped me with figuring out the overhead for my VDSL connection and it ended up being 34, but the recommendation in IpenWRT is still 22. Why is the difference?
VDSL2 (IEEE 802.3-2012 61.3 VDSL2 with PPPoE and VLAN tag):
2 Byte PPP + 6 Byte PPPoE + 4 Byte VLAN + 1 Byte Start of Frame (S), 1 Byte End of Frame (Ck), 2 Byte TC-CRC (PTM-FCS), = 16 Byte
Residual Ethernetheader:
4 Byte Frame Check Sequence (FCS) + 6 (dest MAC) + 6 (src MAC) + 2 (ethertype) = 18 byte
Total: 18+16 = 34 Bytes.
I would not recommend 22 for cable, as that is a value backed up by the standards, unless ds-lite is used, but I digress. The 22 for vdsl2 is much less likely than the other values.
I am fine with a "if in a hurry, set overhead to XX" preamble, but I would really like to keep the correct values, as far as these rather generic recommendations can be correct.
But let's ask Rich brown about his opinion, he wrote the sqm pages to begin with and is very good at keeping things simple, meaning he might agree with you
I'd like it to be accurate as well, but I think from a decision theory perspective, the cost of underestimating is higher than the cost of overestimating... so we should set the numbers in the "quick start" section to be the high end of what we think could happen for that technology (ie. assume there's a VLAN tag and a ds-lite and a whatever stacked up, and tell them to set that). Being too high by 2 or 4 or even 10 bytes has negligible downside for almost everyone who has 5Mbps or more. On the other hand, being too low by 10 bytes would be bad, because then when you're running a big download and you try to squeeze a VOIP call through... it'll break up because your actual bytes sent is larger than what the shaper thinks, so a buffer will form.
I think the see more details section below the list of basic advice on the details page should have absolutely accurate description of what the technology does down to the byte. If they're reading into that section it's now up to them to buy both pieces if they break it I didn't alter that section.
I'll see if I can summon @richb-hanover-priv
1 Like
The difference is due to 2 Byte PPP + 6 Byte PPPoE + 4 Byte VLAN which is not guaranteed to be used on all VDSL2-links, it just happens that your ISP uses that encapsulation. I have way too little information about typical VDSL2-encapsulations encountered in the wild to make a better guess.
Your friend here 
If it does not hurt too much, why not make 44 the default value that is used by Cake (or is it already the case ?)
And BTW, thanks to Cake my bufferbloat is significantly reduced and it not only shows on the DSL Report (A/A+), but also certainly feels on my daily use. Great work!
I think it would be a good idea to create a little tabular "components of overhead" table for the details section. If we do that what are some of the components we should have in it and what are the correct values? (I kind of know where to start looking this stuff up in wikipedia but it doesn't come to the tip of my tongue, perhaps we can come up with a quick list here)
- VLAN
- PPPoE
- PPP
- DS-Lite encap
- Ethernet overhead
- ATM padding
- Carrier Pidgeon food...
Yes, and I am all for putting this in a preamble so everybody has a chance of digesting that
Unlikely on a DOCSIS link, but as far as I can tell not completely alien on other technologies.
That is rather hefty, as it will pull in an additional 40 byte IPv6 header, for a total of 58 bytes on DOCSIS, this is going to be fine if most traffic is IPv6, but in today's still majority? IPv4 world that is an unfortunate price to pay...
True