CakeQOS CakeQOS-Merlin

[ugandy]

Presumably the NAS is on the eth0 interface and the client is on wifi.

That's a bit of a gocha if that's what's happening! Shame though since the wifi to LAN traffic shouldn't require routing. That will need sorting!

I haven't noticed it myself as I don't have any high bandwidth clients connecting directly to that wifi point.

the eth0 interface is the interface to the WAN.

it's for data LAN<->WAN and here cake is in place and it will cap the speed (~40MBps on an ax88).

but i thought the file copy operation described by @rgnldo was LAN<->LAN (and cake shouldn't be involved? )

 

[Toink]

I read the whole thread from page one to the latest. I may have missed that part regarding the extra download/upload options, where/how do you choose the options?

I saw some used ethernet for both, others ethernet dual-dsthost/ethernet dual-srchost.

 

[ugandy]

I read the whole thread from page one to the latest. I may have missed that part regarding the extra download/upload options, where/how do you choose the options?

I saw some used ethernet for both, others ethernet dual-dsthost/ethernet dual-srchost.

what type of ISP do you have? what speeds do you get with speedtest.net?

 

[Toink]

what type of ISP do you have? what speeds do you get with speedtest.net?

My setup is Bridged ONU (FTTH) - Asus RT-AX88U as router.
fiber symmetric 250/250

 

[Wade Coxon]

the eth0 interface is the interface to the WAN.

it's for data LAN<->WAN and here cake is in place and it will cap the speed (~40MBps on an ax88).

but i thought the file copy operation described by @rgnldo was LAN<->LAN (and cake shouldn't be involved )

Ahh of course. I forgot that the download interface was just an alias of eth0. I had myself turned around there.

Unless that wireless traffic was going over a guest WiFi SSID, and had to pass through the WAN interface to get to the main LAN segment?

 

[ugandy]

fiber symmetric 250/250

in that case you don't need ack-filter, just the dual-dsthost/dual-srchost
as for the overhead i use docsis because i have cable.
that user is doing 'ethernet' for overhead.
not sure what is the correct overhead to use for fiber
sounds like ethernet is a valid choice for fiber.

found this online:

SQM: Link Layer Adaptation Tab
The purpose of Link Layer Adaptation is to give the shaper more knowledge about the actual size of the packets so it can calculate how long packets will take to send. When the upstream ISP technology adds overhead to the packet, we should try to account for it. This primarily makes a big difference for traffic using small packets, like VOIP or gaming traffic. If a packet is only 150 bytes and say 44 bytes are added to it, then the packet is 29% larger than expected and so the shaper will be under-estimating the bandwidth used if it doesn't know about this overhead.

Getting this value exactly right is less important than getting it close, and over-estimating by a few bytes is generally better at keeping bufferbloat down than underestimating. With this in mind, to get started, set the Link Layer Adaptation options based on your connection to the Internet. The general rule for selecting the Link Layer Adaption is:

• Choose ATM: select for e.g. ADSL1, ADSL2, ADSL2+ and set the Per-packet Overhead to 44 bytes if you use any kind of DSL/ADSL connection to the Internet other than a modern VDSL high speed connection (20+Mbps). In other words if you have your internet service through a copper telephone line at around 1 or 2Mbps.
• Choose Ethernet with overhead: select for e.g. VDSL2 and set the Per-packet Overhead to 34 if you know you have a VDSL2 connection (this is sometimes called Fiber to the Cabinet, for example in the UK). VDSL connections operate at 20-100Mbps over higher quality copper lines. If you are sure that PPPoE is not in use, you can reduce this to 26.
• If you have a cable modem, with a coaxial cable connector, you can try 22 bytes, or see the Ethernet with Overhead details below.
• Choose Ethernet with overhead if you have an actual Fiber to the Premises or metro-Ethernet connection and set the Per-Packet Overhead to 44 bytes. This can be reduced somewhat for example if you know you are not using VLAN tags, but will usually work well.
• Choose none (default) if you have some reason to not include overhead. All the other parameters will be ignored.

If you are not sure what kind of link you have, first try using Ethernet with Overhead and set 44 bytes. Then run the Quick Test for Bufferbloat. If the results are good, you’re done. If you get your internet through an old-style copper wired phone line and your speeds are less than a couple of megabits, you have ATM so see above for the ATM entry. If you have a slow connection such as less than 2Mbps in either direction and/or you regularly use several VOIP calls at once while gaming etc (so that more than 10 to 20% of your bandwidth is small packets) then it can be worth it to tune the overhead more carefully, see below for extra details.

An important exception to the above rules is when the bandwidth limit is set by the ISP's traffic shaper, not by the equipment that talks to the physical line. Let's consider an example. The ISP sells a 15 Mbit/s package and enforces this limit, but lets the ADSL modem connect at whatever speed is appropriate for the line. And the modem “thinks” (as confirmed in its web interface) that 18 Mbps is appropriate. In this case, the ATM Link Layer Adaptation is likely inappropriate, because the ISP's shaper is the only relevant speed limiter, and it does not work at the ATM level. In fact, it is more likely to work at the IP level, which means that none is the appropriate setting.

 

[ugandy]

Ahh of course. I forgot that the download interface was just an alias of eth0. I had myself turned around there.

Unless that wireless traffic was going over a guest WiFi SSID, and had to pass through the WAN interface to get to the main LAN segment?

he could simply repeat the file operation with cake off and see if it is faster

 

[Toink]

in that case you don't need ack-filter, just the dual-dsthost/dual-srchost
as for the overhead i use docsis because i have cable.
that user is doing 'ethernet' for overhead.
not sure what is the correct overhead to use for fiber
sounds like ethernet is a valid choice for fiber.

found this online:

SQM: Link Layer Adaptation Tab
The purpose of Link Layer Adaptation is to give the shaper more knowledge about the actual size of the packets so it can calculate how long packets will take to send. When the upstream ISP technology adds overhead to the packet, we should try to account for it. This primarily makes a big difference for traffic using small packets, like VOIP or gaming traffic. If a packet is only 150 bytes and say 44 bytes are added to it, then the packet is 29% larger than expected and so the shaper will be under-estimating the bandwidth used if it doesn't know about this overhead.

Getting this value exactly right is less important than getting it close, and over-estimating by a few bytes is generally better at keeping bufferbloat down than underestimating. With this in mind, to get started, set the Link Layer Adaptation options based on your connection to the Internet. The general rule for selecting the Link Layer Adaption is:

• Choose ATM: select for e.g. ADSL1, ADSL2, ADSL2+ and set the Per-packet Overhead to 44 bytes if you use any kind of DSL/ADSL connection to the Internet other than a modern VDSL high speed connection (20+Mbps). In other words if you have your internet service through a copper telephone line at around 1 or 2Mbps.
• Choose Ethernet with overhead: select for e.g. VDSL2 and set the Per-packet Overhead to 34 if you know you have a VDSL2 connection (this is sometimes called Fiber to the Cabinet, for example in the UK). VDSL connections operate at 20-100Mbps over higher quality copper lines. If you are sure that PPPoE is not in use, you can reduce this to 26.
• If you have a cable modem, with a coaxial cable connector, you can try 22 bytes, or see the Ethernet with Overhead details below.
• Choose Ethernet with overhead if you have an actual Fiber to the Premises or metro-Ethernet connection and set the Per-Packet Overhead to 44 bytes. This can be reduced somewhat for example if you know you are not using VLAN tags, but will usually work well.
• Choose none (default) if you have some reason to not include overhead. All the other parameters will be ignored.

If you are not sure what kind of link you have, first try using Ethernet with Overhead and set 44 bytes. Then run the Quick Test for Bufferbloat. If the results are good, you’re done. If you get your internet through an old-style copper wired phone line and your speeds are less than a couple of megabits, you have ATM so see above for the ATM entry. If you have a slow connection such as less than 2Mbps in either direction and/or you regularly use several VOIP calls at once while gaming etc (so that more than 10 to 20% of your bandwidth is small packets) then it can be worth it to tune the overhead more carefully, see below for extra details.

An important exception to the above rules is when the bandwidth limit is set by the ISP's traffic shaper, not by the equipment that talks to the physical line. Let's consider an example. The ISP sells a 15 Mbit/s package and enforces this limit, but lets the ADSL modem connect at whatever speed is appropriate for the line. And the modem “thinks” (as confirmed in its web interface) that 18 Mbps is appropriate. In this case, the ATM Link Layer Adaptation is likely inappropriate, because the ISP's shaper is the only relevant speed limiter, and it does not work at the ATM level. In fact, it is more likely to work at the IP level, which means that none is the appropriate setting.

I remember having to click that link somewhere for the info, and I missed that Ethernet with overhead part!

I really appreciate your quick response! THANK YOU!

 

[ugandy]

I remember having to click that link somewhere for the info, and I missed that Ethernet with overhead part!

I really appreciate your quick response! THANK YOU!

other users in this thread, that use cake with fiber, can share their settings too.

 

[Toink]

Just a thought, perhaps the download/upload extra options should be included in the version of the script? Like an FYI.

 

[ugandy]

Just a thought, perhaps the download/upload extra options should be included in the version of the script? Like an FYI.

but then we couldn't yell RTFM !

on a serious note, yes. presets for connection type (cable, fiber, etc) and use of ack-filter for asymmetric connections could definitely be added to the settings menu. as well as changing script to use dual-srchost/dual-dsthost instead of triple-isolate (maybe). for the rest, reading the man pages is needed because each connection is different

 

[Kingp1n]

in that case you don't need ack-filter, just the dual-dsthost/dual-srchost
as for the overhead i use docsis because i have cable.
that user is doing 'ethernet' for overhead.
not sure what is the correct overhead to use for fiber
sounds like ethernet is a valid choice for fiber.

found this online:

SQM: Link Layer Adaptation Tab
The purpose of Link Layer Adaptation is to give the shaper more knowledge about the actual size of the packets so it can calculate how long packets will take to send. When the upstream ISP technology adds overhead to the packet, we should try to account for it. This primarily makes a big difference for traffic using small packets, like VOIP or gaming traffic. If a packet is only 150 bytes and say 44 bytes are added to it, then the packet is 29% larger than expected and so the shaper will be under-estimating the bandwidth used if it doesn't know about this overhead.

Getting this value exactly right is less important than getting it close, and over-estimating by a few bytes is generally better at keeping bufferbloat down than underestimating. With this in mind, to get started, set the Link Layer Adaptation options based on your connection to the Internet. The general rule for selecting the Link Layer Adaption is:

• Choose ATM: select for e.g. ADSL1, ADSL2, ADSL2+ and set the Per-packet Overhead to 44 bytes if you use any kind of DSL/ADSL connection to the Internet other than a modern VDSL high speed connection (20+Mbps). In other words if you have your internet service through a copper telephone line at around 1 or 2Mbps.
• Choose Ethernet with overhead: select for e.g. VDSL2 and set the Per-packet Overhead to 34 if you know you have a VDSL2 connection (this is sometimes called Fiber to the Cabinet, for example in the UK). VDSL connections operate at 20-100Mbps over higher quality copper lines. If you are sure that PPPoE is not in use, you can reduce this to 26.
• If you have a cable modem, with a coaxial cable connector, you can try 22 bytes, or see the Ethernet with Overhead details below.
• Choose Ethernet with overhead if you have an actual Fiber to the Premises or metro-Ethernet connection and set the Per-Packet Overhead to 44 bytes. This can be reduced somewhat for example if you know you are not using VLAN tags, but will usually work well.
• Choose none (default) if you have some reason to not include overhead. All the other parameters will be ignored.

If you are not sure what kind of link you have, first try using Ethernet with Overhead and set 44 bytes. Then run the Quick Test for Bufferbloat. If the results are good, you’re done. If you get your internet through an old-style copper wired phone line and your speeds are less than a couple of megabits, you have ATM so see above for the ATM entry. If you have a slow connection such as less than 2Mbps in either direction and/or you regularly use several VOIP calls at once while gaming etc (so that more than 10 to 20% of your bandwidth is small packets) then it can be worth it to tune the overhead more carefully, see below for extra details.

An important exception to the above rules is when the bandwidth limit is set by the ISP's traffic shaper, not by the equipment that talks to the physical line. Let's consider an example. The ISP sells a 15 Mbit/s package and enforces this limit, but lets the ADSL modem connect at whatever speed is appropriate for the line. And the modem “thinks” (as confirmed in its web interface) that 18 Mbps is appropriate. In this case, the ATM Link Layer Adaptation is likely inappropriate, because the ISP's shaper is the only relevant speed limiter, and it does not work at the ATM level. In fact, it is more likely to work at the IP level, which means that none is the appropriate setting.

Awesome explanation and I like to have options...so with that said ...what would you recommend if I have comcast (cable) with 100/10 mbps speeds. Someone recommended to try 'ack-filter' with these type of speeds or start with default settings... Thoughts?

 

[ugandy]

Presumably the NAS is on the eth0 interface and the client is on wifi.

That's a bit of a gocha if that's what's happening! Shame though since the wifi to LAN traffic shouldn't require routing. That will need sorting!

I haven't noticed it myself as I don't have any high bandwidth clients connecting directly to that wifi point.

oh. i wonder if it could be because HW acceleration is turned off for cake?

that affects LAN<->WAN but likely LAN<->LAN too, no?

if this is the case, it is a big limitation, that the wifi to wifi transfer speeds and available wifi to wifi bandwidth are capped when using cake.

i don't have a lot of client-to-client transfers, but if someone does (NAS, etc) this is a concern.
should be clarified

 

[ugandy]

Awesome explanation and I like to have options...so with that said ...what would you recommend if I have comcast (cable) with 100/10 mbps speeds. Someone recommended to try 'ack-filter' with these type of speeds or start with default settings... Thoughts?

this is what i use for my comcast:

[1]  --> Download Speed             | [285 Mbit]
[2]  --> Upload Speed               | [0 Mbit]
[3]  --> Queue Priority             | [besteffort]
[4]  --> Extra Download Options     | [docsis dual-dsthost]
[5]  --> Extra Upload Options       | [docsis ack-filter dual-srchost]

note that i use zero for upload because my local node upload changes during the day (from 2Mbps to 20Mbps).
it you have stable max speed on your connection, a non zero limit gives better results than using zero
i use ack-filter on the upload to help reduce bloat there. not needed on download since i have enough bandwidth there; using besteffort because available categorization is poor for diffserv4, apparently (i'm conforming to info found on bufferbloat.net and on this thread). also using 285 on the download because that appears to be a cake hardware limit on ax88.
but note, some people use zero for both with good results. depends on your connection.

start with 95/9 and check results
(this is, use 95% of your speeds, as measured by spdMerlin with cake/qos off)

 

[kernol]

Fiddle faddle and flip flop between one "tweak"and another ... Why? ... in the end just stick to KISS ...

I have Fibre 100/50 and am a million miles from DSLReports test servers - see hectic slow ping times ... yet receive best QOS results with super simple ...

/jffs/scripts/cake-qos start 93Mbit 46Mbit "besteffort"

Just set and forget ... and understand that if you have dreadful ISP supplied bandwidth speed and or quality - no amount of fiddling with Cake will miraculously cure inferior base supply.

If you want to tweak away with granular control over shaping - or just love fiddling ... rather go with FlexQOS and fine tune to your hearts content .
Let's keep Cake-QOS in KISS mode .

 

[New2This]

Running 1Gbps/30Mbs, anyone else running cake-qos, seeing any benefit

Bufferbloat here could use some help

 

[ugandy]

Fiddle faddle and flip flop between one "tweak"and another ... Why? ... in the end just stick to KISS ...

I have Fibre 100/50 and am a million miles from DSLReports test servers - see hectic slow ping times ... yet receive best QOS results with super simple ...

/jffs/scripts/cake-qos start 93Mbit 46Mbit "besteffort"

View attachment 24496
Just set and forget ... and understand that if you have dreadful ISP supplied bandwidth speed and or quality - no amount of fiddling with Cake will miraculously cure inferior base supply.

If you want to tweak away with granular control over shaping - or just love fiddling ... rather go with FlexQOS and fine tune to your hearts content .
Let's keep Cake-QOS in KISS mode .

not always true
KISS approach did not give me best results on my comcast line (not everybody has fiber).
shouldn't i have tried until i found my best cake results?
FlexQoS was, unfortunately, unable to control my buffer bloat in any shape, form or fashion. the graphics were pretty

 

[XIII]

• Without cake-qos I score bufferbloat B; with cake-qos (up/down either 90% or 95%) I still score B...
• With cake-qos enabled I loose about 16% up/down Mbps

Does this mean cake-qos has only disadvantages in my situation and I should not be using it?

Or do I misunderstand why so many people are enthusiastic about it?

These are my current settings for my 250/25 connection:

[1]  --> Download Speed             | [225 Mbit]
[2]  --> Upload Speed               | [22 Mbit]
[3]  --> Queue Priority             | [besteffort]
[4]  --> Extra Download Options     | [docsis ack-filter dual-dsthost]
[5]  --> Extra Upload Options       | [docsis ack-filter dual-srchost]

Note that it's the Ookla speedtest CLI on the router (AC86U) itself that reports the 250/25 that are in my ISP's advertising; DSLReports gives lower values with/without cake-qos...

 

[ugandy]

• Without cake-qos I score bufferbloat B; with cake-qos (up/down either 90% or 95%) I still score B...
• With cake-qos enabled I loose about 16% up/down Mbps

Does this mean cake-qos has only disadvantages in my situation and I should not be using it?

Or do I misunderstand why so many people are enthusiastic about it?

These are my current settings for my 250/25 connection:

[1]  --> Download Speed             | [225 Mbit]
[2]  --> Upload Speed               | [22 Mbit]
[3]  --> Queue Priority             | [besteffort]
[4]  --> Extra Download Options     | [docsis ack-filter dual-dsthost]
[5]  --> Extra Upload Options       | [docsis ack-filter dual-srchost]

Note that it's the Ookla speedtest CLI on the router (AC86U) itself that reports the 250/25 that are in my ISP's advertising; DSLReports gives lower values with/without cake-qos...

i would install pingplotter and observe the latency during the spdMerlin test, and compare with/without cake

or check the latency numbers on the fast.com test

 

[ttgapers]

but then we couldn't yell RTFM !

on a serious note, yes. presets for connection type (cable, fiber, etc) and use of ack-filter for asymmetric connections could definitely be added to the settings menu. as well as changing script to use dual-srchost/dual-dsthost instead of triple-isolate (maybe). for the rest, reading the man pages is needed because each connection is different

Yeah been in the industry toooooo long to keep redundant data all over the place. The link for Advanced Users (Tweaking) is handily posted on Post #1 for all....so feel free to yell RTFM

Just kidding, loving the community support on these forums from since 2014 as my handle says. Happy to be able to semi-contribute back!