Wan Packet Overhead For Qos

[Vexira]

is adaptive qos sqm (smart queue mangement) or pure qos, ive been reading that sqm adds an exrta 14 bytes for vdsl 2 over head hence why they suggest adding 8 for pacet overhead since it adds up to 22 if not then 22 is the proper value for a vdsl 2 connection as over head.

 

[Vexira]

This might help some one
Get the value of their overhead
https://web.archive.org/web/20120317165750/http://ace-host.stuart.id.au/russell/files/tc/tc-atm/

 

[Vexira]

I'm starting to believe it's 28 after running a ping via cmd and downloading on steam the ping is not rising much.

 

[Vexira]

ok so acordink to these
https://lists.bufferbloat.net/pipermail/cake/2015-May/000182.html
https://lists.bufferbloat.net/pipermail/cake/2015-May/000183.html
https://lists.bufferbloat.net/pipermail/cake/2015-May/000184.html
pppoe-ptm= 26 not 27
bridged-ptm = 18 not 19
which contradicts the values here
https://github.com/lede-project/sou...ils/iproute2/patches/950-add-cake-to-tc.patch

 

[FreshJR]

So for you guys setting packet overhead. Are you still using a percent of your total available bandwidth speed, albeit a lower one now?

I didn't do enough testing in this area.

 

[MarioCaires]

Yes FreshJR, in my case I could increase the Download from 50Mb to 58Mb. Receiving 62 from my ISP...

 

[FreshJR]

Yes FreshJR, in my case I could increase the Download from 50Mb to 58Mb. Receiving 62 from my ISP...

But your raw speed throughput, the packet payload, surely had to stay the same? Unless the previous qos values had a significant room for error

 

[MarioCaires]

But your raw speed throughout, the packet payload, surely had to stay the same? Unless qos the previous qos values had a significant room for error

OMG... My bad, you're right! Never bothered to check it properly...

 

[Vexira]

So for you guys setting packet overhead. Are you still using a percent of your total available bandwidth speed, albeit a lower one now?

I didn't do enough testing in this area.

As far as my research goes it's more like overhead from protocols such as pppoe clan tags, and a few other things, that determine the performance packet overhead. All or it are in the links I posted.

 

[FreshJR]

As far as my research goes it's more like overhead from protocols such as pppoe clan tags, and a few other things, that determine the performance packet overhead. All or it are in the links I posted.

But are we not double accounting for this overhead transmission protocol with the ISP.

My speed is rated at 30mbps and without qos I get that full 30mbps of throughput on speedtest.

Now I'm not sure if those results are 30mbps of pure packet payload or both the packet payload and all it's headers (guessing 2nd one)

Either way, once at my router all packets have standard headers without any premodem overhead. Any of this overhead is stripped by the modem itself.

How do you know that the isp is not white listing this additional packet from their transmission protocols ensuring I always get 30mbps throughput of standard header and payload data. Aka, how do you know we are not double accounting.

For cable intenet, doesn't the modem download the provisioning file and its the modem itself dropping packets to meet the stated bandwidth limits in this provisioning file. I'm almost certain the modem ignores incomming tramission overhead and that bandwidth limitations are done on egress traffic. Pretty sure that no bandwidth limiting is done on the supply node saving complexity and processing power.

In short we maybe are double accounting for this packet overhead and just pumping up our qos bandwidth percent setting up a few percent to reach the same end result.

 

[Vexira]

But are we and the isp double accounting for this data.

My speed is rated at 30mbps and without qos I get that 30mbps of throughout on speedtest.

Now I'm not sure if those results are 30mbps of the packet payload or both the payload and all the headers (guessing 2nd one)

Either way, once at my router all the packets have standard headers. Any overhead is stripped by the modem.

How do you know that the isp is not white listing the additional packet for their transmission protocols and the isp ensuring I always get 30mbps of standard headers and payload. Aka, how do you know we are not double accounting.

your not double accounting with a per pacet overhead, your in the words of merlin improving the accuracy of qos bandwidth shaping, it allows qos to take the extra protocols into account, and adjust its shaper accordingly.

 

[FreshJR]

your not double accounting with a per pacet overhead, your in the words of merlin improving the accuracy of qos bandwidth shaping, it allows qos to take the extra protocols into account, and adjust its shaper accordingly.

This overhead setting that pumps up the raw metered speed actually going through the router by a changing value to account for a stripped/now invisible portion of the entire packet that was present before the modem itself processed packet.

This value is consistently calculated based on incoming packet rate to account and estimate this now invisible, to the router, portion of the packet. This allows the router to estimate the true packet size before it was processed modem.

The original qos bandwidth reading only accounted for the entire packet size from the Ethernet header up to the final payload. Aka, the full throughput, through the router.

But this raw router throughput is the same value that the modem is limiting on, since the modem is limiting egress not ingress traffic.

So with this overhead setting we are double accounting for something we are actually not limited on. How could this be more accurate? Originally the bandwidth meter did read the standard packet overhead reflecting what was physically passing through the router and that was correct.

I can only see offering more accuracy if some ISP are bandwidth limiting on this original overhead (ingress modem traffic). From my experience, Comcast does not.

 

[Vexira]

But before we had this overhead setting that pumps up the raw speed read by the bandwidth metered based on incoming packet rate, wasnt qos reading the entire packet size from the Ethernet header up to the final payload into the bandwidth meter.

Now with this overhead weldong it still be reading the entire packet size, from the Ethernet header up to final payload, and then adding a kb/s to that bandwidth meter to account for the stripped overhead that occurred before the modem.

So it's double accounting for something we are not limited on. How could this be accurate. Original bandwidth meter read the standard packet overhead as that was physically passing through the router

From post 431 here
https://www.snbforums.com/threads/release-asuswrt-merlin-380-61-is-now-available.33994/page-22

"To accurately calculate QoS handling, the kernel needs to know the size of a packet. People with ADSL connections have some additional data added to every packet (at the ATM level), which means that the kernel's calculations are off by a few bytes.

This setting allows you to tell the kernel if there is any overhead to be added to each packet. Cable users are typically set to 0 (since there's typically no additional overhead added by the ISP). This is what the kernel was assumg in the past.

This setting is really only for people trying to finetune their QoS to the extreme. The only drawback of not accurately configuring this is some bandwidth gets wasted." - Merlin

 

[FreshJR]

How is this data not stripped once it leaves the modem into standard Ethernet headers even on ADSL connections.

I can understand why it would be present on any signal before the modem.

Pretty sure the drop down set my overhead at 18 once I selected a cable network. Issue is that comcast is not bandwidth limiting this overhead traffic as limits are applied by the CABLE MODEM on egress traffic, not by the NODE on egress traffic. This reaffirms my double accounting concern.

I understand the sense this setting makes when applied for users that actually are limited on this overhead.

If your speedtest results are always a tad lower than provisioned speed, then you can be sure you are limited on packet overhead traffic invisible to your router.

 

[Vexira]

How is this data not stripped once it leaves the modem into standard Ethernet headers even on ADSL connections.

I can understand why it would be present on any signal before the modem.

Pretty sure the drop down set my overhead at 18 once I selected a cable network. Issue is that comcast is not bandwidth limiting this overhead traffic as limits are applied by the CABLE MODEM on egress traffic, not by the NODE on egress traffic. This reaffirms my double accounting concern.

I understand the sense this setting makes when applied for users that actually are limited on this overhead.

If your speedtest results are always a tad lower than provisioned speed, then you can be sure you are limited on packet overhead traffic invisible to your router.

my modem is in brige mode all routing is disabled, also my speed is lower due to my copper cable since im on vdsl2, its 25 years old and the cable pits are horrid my area suffers from congestion on the nodes.
Read some of the links i posted that might explain in greater detail, merlin is using the lede project values as a refrence keep in mind the values he gathered are intended for cake-fq_codel so i suppose cakes shaper may or may not add extra overhead values. Im not a net work engineer you best off asking the guys who wrote the qos, and merlin. Though i so think the overhead values is for people who set the full speed test value into qos, that is literally what the asus gude tells you to do. But i strongly advise to read the links i posted, im sure that the over head is to do with the shaper. Here in austrlia isps are lazy as hell so its possible they are not doing things propperly, im with optus, but telstra owned the hardware before nbn co took over, and telstra was horrible.

 

[Vexira]

i think what your worried about is shouldnt the isp handle all of this in there shaper before it reaches the modem and are we artificcaly loading down the connection, all of which is a valid concern. Idealy yes it should be stripped at the isp end, but in pratice, that i have no idea.
I gueas its equvalent to setting your bandwith to 95% but in a more acccurate way, i did read for vdsl1/2 its about 9% or such its to do with some thing complex its better explained in the links but it makes more sense if you scroll though them, im not entirely sure about cable since my reaserch was entirely devoted to vdsl2 and trying to find the rightbover head for Ipoe llc based bridge mode per pacet overhead. If you so desire i can see if i can't find more info about cable.

 

[Vexira]

also here ius the lede project thing
https://github.com/lede-project/sou...ils/iproute2/patches/950-add-cake-to-tc.patch
for you to take alook at

 

[MagikMark]

After choosing any of the preset. Is it necessary to change the MTU of the router or OS by deducting the ATM value to the default MTU?


Sent from my iPhone using Tapatalk

 

[Vexira]

After choosing any of the preset. Is it necessary to change the MTU of the router or OS by deducting the ATM value to the default MTU?


Sent from my iPhone using Tapatalk

Tick the atm box, if your internet uses atm. Otherwise everything should be fine.

 

[MarioCaires]

I've found this utility to automatically calculate an ATM overhead! Keep in mind, as mentioned in the readme, it only gives reliable results for an ATM link so basically it is only for ADSL connections!

https://github.com/moeller0/ATM_overhead_detector