My ISP provided MTU is 1460, and the connection is jittery. Any way to fix it using SQM?
Probably not. The thing is SQM requires fixed rate links to work properly. You could try to start with SQM set to only 50% of the download and upload bitrates you achieve in on-line speedtests. If that does not reduce the jitter to something acceptable, SQM will not be the solution to your issues. if it does, then iteratively try to increase the shaper rates until latency under load or jitter get unacceptable...
That might mean that you need to add 40 Bytes to the applicable per packet overhead. This "smells" a bit like an IPv6 based tunnel that adds the 40 byte IPv6 header.
How do I go about doing this?
They do provide Public IPv6, which is very much unstable at this point.
Have a look at https://openwrt.org/docs/guide-user/network/traffic-shaping/sqm-details#sqmlink_layer_adaptation_tab. Depending on your link type you would add 40 bytes to the recommended per-packet-overhead value.
Mmmh, which ISP is that, if I may ask, and which technology?
I'm from India, and it's a FTTH (fiber) connection back here. The ISP is BSNL, which is known for it's worst peering, since we live in a remote area, we have nothing but that. The packet overhead is only available for ATM and VDSL2, which one is recommended for my type of connection?
According to https://www.reddit.com/r/bsnl/comments/ht37q4/guide_for_bsnl_ftth/ they seem to use GPON or EPON. The first step should be to figure out which, what modem are you using (maker and model)? That should help to figure this out?
I assume GPON, and I think that for GPON the per-packet-overhead shpould be >= 23 Bytes (or of there is a "hidden" IPv6 tunnel >= 23+40 = 63 bytes).
1 Like
Yes, it's a GPON device. I'm using Genexis Earth 1000R ONT https://www.gxgroup.eu/wp-content/uploads/2021/01/Datasheet_Earth-1000R_3d.pdf
I have enabled Ethernet with Overhead with Per Packet Overhead set to 23, does that sound correct? I have disabled IPv6, it doesn't tunnel through IPv6, as far as I know.
Mmmh the linked document says: " * Support both EPON and GPON mode"
As far as I understand GPON yes, but I openly admit that I do not know the true applicable overhead in your case. Most ISPs use some sort of traffic policer or shaper and typically one needs to account for the maximum of the overhead configured for that shaper and the true overhead on the actual bottleneck link. The 23 Bytes is my best guess for the true per packet overhead on the GPON path, but what the ISP does, I have no idea.
For EPON I would expect 38 bytes of overhead, the same as true eternet, but again, I have neither first hand experience with EPON nor GPON.
Yes, it's an XPON, it supports both connections but the one coming from my ISP is GPON. I have checked with them as well.
My ISP caps at 1460 MTU, the 23 Byte overhead is correct for the provided MTU value, right? Just to reassure.
Well, the question here is, why MTU 1460? If this is because your ISPs upstream uses a tunnel, these 40 bytes should not matter for you, but if you ISP uses some sort of IPv6 tunnel (like in ds-lite) on your GPON link you need to account for these 40 bytes as well.
Hard to tell from the outside.
And I guess only for IPv4 packets 
If their IPv6 connectivity is broken I can understand this. But IPv6 is a great technology and you should absolutely welcome it if it's working.
Yes, but @vampirexox has disabled IPv6 so all traffic should be IPv4.
True, once the ISP does get it right 
1 Like
I have set the following settings to Link Layer Adaptation. Will revert back after testing it. @moeller0 @dlakelan
Reverting back to what? I can almost guarantee that the default 14 byte that the linux kernel accounts for will be too little