Hi I want help with options sqm
Per Packet Overhead (byte):
for 5g 
Good question. But I have no reply, but that is already true for 3G and 4G as well. And honestly, SQM needs both information about the applicable overhead and the available fixed rate, which on variable rate links as 5G is a challenge.
Yes, I searched for two weeks without an answer. I hope scientists have a solution 
Science says that overhead is rarely a critical number, as errors in overhead make almost no error in rate estimate unless packet sizes are small. Choose something that's likely to be an overestimate. I'd suggest 50bytes... And move on to the bigger problem: what speeds to put?
actually since sqm needs to give priority to small packet... ack and others, the overhead option is very important. In my case at times with a vdsl of 200 mb a wrong overhead caused increasing upload latency while the correct number keeps it at 0.
Enable this SQM instance.
Interface name
eth1.2 (wan,wan6)
Download speed (kbit/s) (ingress) set to 0 to selectively disable ingress shaping:
400000
Upload speed (kbit/s) (egress) set to 0 to selectively disable egress shaping:
30000
cake
test_WAN_triple-isolate__piece_of_cake.qos
Overhead matters a little, but it doesn't matter anywhere near as much as making an error in the speed settings. If you put 30 as overhead and your real overhead is 37 and you are sending an ACK which is ~ 70 bytes then you'll calculate its size as 100 bytes and its true size will be 107 which means a 7% error. Since the error is an under-estimate, this is bad as you'll potentially send more data than you really can fit through your pipe and something somewhere will start to buffer (like your modem). However, if you have overhead of 37 and instead put 40. All this does is it ensures that you overestimate the size of packets, and that you never over-fill an upstream buffer, and you fail to get the last ~ 2% or something from your speeds, which in fact you probably shouldn't be trying to shave that close to the maximum speeds anyway.
If Acks are 50 percent of your upstream (and if they are, you should absolutely be using ack-filter) then your error in bandwidth calculation is 7% * 0.5 = 3.5% and this is basically kind of the worst case. Flooding upstream with acks, means all the packets are small. But if your packets are 1500 byte upload data packets... your size error is 7/(1537) = 0.45% which is basically negligible. So if you're doing a bidirectional transfer with 50% large packets and 50% acks, your total size error is going to be something like 3.5%. DOCSIS modems have ack-filters built in, and so in fact you'll be way overestimating your bandwidth usage anyway, better to use cake's ack-filter and eliminate those things anyway.
Now if you do a speedtest and get 200mbps but in fact there is error in the speed-test and furthermore the real bandwidth fluctuates somewhat throughout the day, then this is a far bigger problem than the overhead. And if you solve this problem by cutting 15% off your peak speed, so you put 170Mbps then it solves all the problems including not knowing the overhead exactly.
So the solution to not knowing the overhead is to always just estimate something slightly higher than it's really likely to be. If you're on DOCSIS put say 25 or 27. If you're on VDSL or GPON put 40 or maybe 45. Then take your speedtest speeds from 5 different speedtests, and take the minimum for each direction, take 95% of that, and you're good to go.
If you've got asymmetric speeds, use ack-filter on the upstream.
However, if you've got variable speed 5G link... it's hard to do anything really useful.
1 Like
Sorry @Ops for hijacking the thread.
@dlakelan, How can ack-filter exactly be useful? should it only be used on asymmetric speeds?
The biggest rational for ACK filtering is a bursty link where ACK compression happens the reduction in useful bandwidth from eliminating a few redundant ACKs is a secondary benefit (in most conditions).
ACK compression is well explained in http://yuba.stanford.edu/buffersizing/selected-papers/ZSC91.pdf and is caused when an ACK stream deviates too much from an ideal more or less isosynchronous behavior and bunches of ACKs are released in bursts of closely spaced packets. Depending on the rate WiFi and DOCSIS links are bursty enough to merit ACK filtering, mobile links like this threads 5G probably also qualify...
Other than that, I concurr with @dlakelan, that overstimating the per packet overhead is pretty benign and with @Ansuel thatunderestimating it can have pretty obvious bufferbloat side effects, so if in doubt be generous when guessing the overhead value 
1 Like
However on asymmetric links, doing a big download can lead to the upload bandwidth being largely used up just by acks, leaving not enough bandwidth for important things. In this case the bandwidth reduction on the uplink becomes a major help. For example if you have 600Mbps down and 15Mbps up as my friends parents do on Comcast, then at peak download you send something like 600000000/(1500*8)/2=25000 acks per second. If an ack is around 800bits then this is 20Mbps of acks which completely clogs the upstream. However the modems do ack suppression so they're throwing away up to maybe 90% of the acks. Cake doesn't know this though so it's going to restrict you to configured 15Mbps which means essentially nothing but acks will be allowed through. In any case the ack filter is a huge benefit for this sort of thing.
2 Likes
How so? The worst asymmetries I have seen are in the 1:20 range, while the ACK to reverse data ratio is 1:40, so there is still room for egress data... and delaying these ACKs by giving other packets priority over them, will also slow down the downloads reducing the ACK rate somewhat. Now, if you really argue for maximizing downloads, then ACK filtering will make sense again, as you improve the timeliness of the "ACK-clock" and hence downloads tend to continue smoothly.
Now an ISP that provisions 600/15 or 40/1 really needs a stern talking to, because that is insane... BUT, in case one's ISP demonstrates that level of lack of scruples, ACK filtering will be a big argument for cake 
I heard opinions on the quality of DOCSIS modem ACK-suppressors and these opinions are not fit for younger audiences... IMHO ACK filtering needs to be opt-in by the enduser and not something an ISP should activate on its own to paper over insanities like provisioning an up/down ration of 1/40...
Sidenote, more modern TCPs tend to send fewer ACKs than one per any two full MSS packets, but the issue still persists.
Yes, and these ACKs will not really queue up in the modem and hence the modem's ACK suppressor will not trigger.
Oh, I am not arguing against the ACK filter, but trying to explain that the primary effect is smoothing out the ACK stream to increase the usefullness of the ACK clock to control the sending side.
1 Like
I agree with all of this, but here in the US it seems cable companies still think their real purpose is to shove popular culture down your throat in a one way stream. So they seem to provision on the basis of "just enough upstream to send the acks for our streaming content". I love my symmetric fiber.
COVID may be convincing people there's "something wrong with the internet" but I think mostly because they don't know what's wrong they aren't specifically demanding actually better internet from the cable companies (I think for most people the sweet spot is near 100Mbps symmetric).
EDIT: It's actually really HARD to find out what upstream speed cable companies are offering in the US... they don't advertise it ANYWHERE, even when you click the fine print. The most reliable source is 3rd parties. It's as if upstream doesn't even exist for them.
1 Like