Hi, my sister is using a stable 3g uplink without limitation. So i would like to set up and test sqm on her LEDE router.
The question is just: What is the per packet overhead in bytes for a 3g connection?
Greetings.
In the Link Layer Adaptation tab, choose the kind of link you have:
- For VDSL - Choose Ethernet, and set per packet overhead to 8
- For DSL of any other type - Choose ATM, and set per packet overhead to 44
- For Cable or other kinds of connections - Choose none (default)
@Knomax That does not answer the question.
I have just set up a PCEngines Alix (Geode x86) with a 3g mobile dongle plugged into a USB port.
This works very well - but the question:
What is the per packet overhead in bytes for a 3g connection?
I have a Pumpkin HSDPA dongle with a 3-network sim in the UK and by quick trial and error it seems to work best set to DSL/ATM(44), but would something else be better?
1 Like
Not to rain in on your parade, but the ATM_overhead_detector will only ever produce something meaningful for real ATM based links*. I would really be amazed if any mobile operator would use ATM over its wireless network, so in all likelihood running the ATM_overhead_detector is not going to help...
One method to use without the "luxury" of ATM cell quantization, is to create saturating loads with different packet sizes, while playing with sqms bandwidth and overhead parameters (as long as both the precise bandwidth and overheads are unknown this is a bit approximate, please note the relevant numbers are not necessarily the rate and overhead on 3g's air lonk, but rather the user visible limits, which might be created by a shaper using different rate and overhead settings):
-
with full MTU packets measure the maximum user (net) bandwidth achievable, then calculate the estimated gross rate that corresponds to that rate by using publically researcable information about 3G's encapsulation. Also measure bufferbloat (this should be high)
-
Start to configure sqm with the estimated gross rate, and measure again, bufferbloat should still be high.
-
iteratively increase the overhead value until the bufferbloat measurements get better.
-
set the MTU to a small size (the smaller the better, unless your link also has a PPS limit) and repeat the easurment with sqm's rate and overhead values; if the overhead estimate was to small, bufferbloat will be high; if bufferbloat stays low, you seem to have a decent overhead value estimate.
-
Finally set the downstream bandwidth to ~90% of the measured rate to get a bit of slack for multiple inrushing connections...
Challenges: since mis-estimating the per packet overhead effectively increases or decreases the consumed bandwidth in relation to the set bandwidth, it is not trivial to deduce both unknown bandwidth and overhead simultaneously, so it makes sense to take any result with a grain of salt and try to measure at multiple different packet sizes.
In cas you can coax your sister's ISP to give detalled information about the applicable overhead, please take the time to post the results in this forum thread...
Hope this helps
*) it relies on the fact that ATM/AAL5 insist upon packaging each user data frame in an integer number of ATM cells, padding out the unused bytes; this will lead to a stepwise increase in RTT of packets, where the "steps" occur every 48 bytes, the offset of these steps together with the information about the user visible overhead (IPv4, ICMP...) then allows to deduce the invisible overhead component; as far as I know only AAL5 has this quantization property and hence ATM_overhead_detector's method will only work with ATM/AAL5 links.
1 Like
What did the trick for me was to test the real average speed with nperf. Even if the max bandwidth i can get is 1mbit up/down, the real average rate was about 600kbit. Using sqm around this value work great.
But i still dont have the real overhead, neither the MTU.