Hello, I'm looking for ways to calculate per packet overhead on my network for SQM. Unfortunately, I'm on a variable speed wireless ISP, and there is little to no documentation on it for this kind of set up. Therefore, I'd like to find out for myself if people don't know off-hand.
However, I have the luxury of working at my ISP so I know exactly what kind of equipment is being used. For topology, my router plugs into a Ubiquiti Powerbeam 5AC, which uses IEEE 802.11ac and transmits to a Rocket 5AC Prism tower, to a Calix E7, and from then onward is on fiber.
What kind of per packet overhead would I be looking at and/or is there a way for me to definitively test and calculate it?
So WiFi is tricky... the biggest issue is that there is a massive overhead for listen-before-talk that is in units of time, so its effect is hard to translate into a fixed packet size increase (the fixed time delay corresponds to differently sized overheads depending on the transmission speed used for the transmit opportunity)... in addition the actual link rate is not going to be fixed anyways, so even knowing the exact applicable overhead will only help a bit... @maurer's advice is good, as would be to as your ISP to have a look at libreqos which might help in solving bufferbloat in the ISP->homenet direction. Maybe @dtaht could give his assessment whether libreqos might help, please?
The wifi per packet overhead problem is difficult to handle with sqm. It actually is not the per-packet overhead, but successfully forming the right size aggregate. We solved it by replacing the entire linux wifi stack with this: https://www.cs.kau.se/tohojo/airtime-fairness/
It has generally been my hope that an ISP would first leverage that codebase for p2mp wifi traffic, and then put libreqos on top of it. Without the APs intelligently forming aggregates you end up degrading performance to just what you can get with minimal aggregation. I do not know enough about the wifi drivers in any of your gear to be able to say anything more than that. LibreQos lets you measure the real effects of applying cake to subscribers on links like that, and we have plenty of people in the chat room that might have experience with your set of gear worth talking to.
Dies not seem to have a web interface, am I missing something? (Not a fan of the push for one app for every service, it might well be fully justified in this case, but it always makes me weary and hesitant)
Thanks for the info, I'll look into libreqos further and I am already using the adaptive bandwidth script that @maurer suggested!
I totally agree that per packet overhead may not matter as much as getting the speed consistently right, but I'm quite literally trying to squeeze water out of rocks with my connection haha. You kinda have to when you're trying to properly divvy up 30 over 5 in a high usage house. Therefore, I'm dead-set on a quest to create my personal SQM configuration to be optimized razor sharp.
Don't have to ask me twice! I'm definitely going to be researching this and maybe even begin work on possible implementation as soon as I'm walking in the door on Monday.
I'll pursue to the ends of the Earth in my quest for low latency gaming lol.
Alas shaper rate and per packet overhead are not orthogonal parameters, if you overestimate the overhead that will result in less throughput, and if ypu underestimate the overhead ypu can make up for it by reducing the shaper rate... now both behave a bit differently for packets of differing size, but that is a small detail as most bulk traffic tends to use maximally large packets.... The result of this is, that we recommend to err on the side of more for the oberhead and less for the shaper rate. However with cake-autorate this becomes rather less important, as it will adjust the shaper based on observed delay, and hence correct for incorrect overhead settings, to be on the save side though I would still recommend to rather specify too large an overhead...
I do wonder, how does cake-autorate perform with an oversaturated ISP?
In theory, would it make it worse? Ie, the latency, especially when we talk peek ISP sag hours, comes from an external source and not a download? Would the script see that and keep the speed at the minimum, and potentially choke out your connection, where-as the lesser of the two evils is the higher speed considering regardless of speed, you have high latency?
Idk, at least for my situation, I'm thinking no amount of SQM tuning would help in hindsight. Not when the ISP tower has about 120 megs to split between 20 house-olds on 30/4 plans. When my max speed drops from 30 to about 10 megs in the evening, I really don't think there's much I can do.
Any tips or advise would surely be appreciated though!
It will adjust the rate down if the experienced latency exceeds your threshold until it hits your configured minimum rates...
Well if 10 is the true minimum then cake-autorate might get you there with less queueing delay, but that depends on your WISP as well... (sidenote if this truly is a wisp maybe steer them to libreqos, which if they would deploy it might help with bufferbloat in the download direction)
yep. Please tell your wisp about libreqos... if your wisp is THAT oversubscribed, it has a model of the network that can be applied to make sure it degrades gracefully, which sqm-autorate can only infer.