CakeQOS CakeQOS-Merlin

[Wade Coxon]

Now as far as cake goes, after dong a bunch of reading I'm wondering if the bandwidth limiting with fq_codel is cake is one and the same. Native Wort has it as a standard package. The wording "Traditional QOS" appears to be an Asus term. Historically (Traditionally) QOS was implemented by classifying and tagging. I posted the history of the issue I was having yet the use of bandwidth limiting is probably the more interesting thing I'm presenting. Possibly I should have done this as separate posts.

It's not. fq_codel is just a new and slightly improved queuing discipline tacked onto the front of the normal Asus QoS engine. Cake is quite a bit more than that. Read up at bufferbloat.net for all the gory details which should elaborate on the video you posted.

If you want to use the Asus QoS implementations, then you should check out the FlexQoS thread for the improved application tagging rulesets, and other enhanced features.

 

[brummygit]

What are the problems you have with Ring cameras? I have a doorbell camera and 3 stick-up cameras and don't have any issues with cake or the router giving remote access to the cameras.

I have a Ring Doorbell Pro so permanently powered. My issues are with Live View - it's either very slow to start the video, never starts the video and sits with a black screen (sound is working) or video breaks up with a message about a weak signal.

I have a dedicated router providing a dedicated SSID on it's own unused 5Ghz channels about 1 foot away from the doorbell through a window and sufficient bandwidth that all should work fine. The problems are actually worse if I am using a device on my home network to view. My iPhone on 4G works better than my iPhone on my home network.

I know that Live View streams it's data up to the Ring servers and then back down to my viewing viewing device and I have suspicions that there is some kind of conflict between the upload and download streams running at the same time - port, NAT or similar

 

[Yooshaw]

I have a Ring Doorbell Pro so permanently powered. My issues are with Live View - it's either very slow to start the video, never starts the video and sits with a black screen (sound is working) or video breaks up with a message about a weak signal.

I have a dedicated router providing a dedicated SSID on it's own unused 5Ghz channels about 1 foot away from the doorbell through a window and sufficient bandwidth that all should work fine. The problems are actually worse if I am using a device on my home network to view. My iPhone on 4G works better than my iPhone on my home network.

I know that Live View streams it's data up to the Ring servers and then back down to my viewing viewing device and I have suspicions that there is some kind of conflict between the upload and download streams running at the same time - port, NAT or similar

I have a similar setup, but 1 Floodlight Cam and the Doorbell 2 connect to an AP (AC-68U) - but I have some other IOT devices also connected to this AP, but their bandwidth is minimal. The other Floodlight Cam connects directly to the Router (AX-88U).

My battery powered (but connected to mains) Doorbell 2 is almost flawless, but the two mains powered Floodlight Cams have same issue of not starting live view. Seems the common thread here with the Ring Cameras are the ones that are mains powered seems to have issues.

I'm hoping the "nonat" permanently fixes the main issue for me with the Floodlight Cams, which was no live view. This happened whether on the same network, or roaming from my cell phone.

 

[Morris]

It's not. fq_codel is just a new and slightly improved queuing discipline tacked onto the front of the normal Asus QoS engine. Cake is quite a bit more than that. Read up at bufferbloat.net for all the gory details which should elaborate on the video you posted.

If you want to use the Asus QoS implementations, then you should check out the FlexQoS thread for the improved application tagging rulesets, and other enhanced features.

Bin down that rabbit trap. Flex QOS sits on top of Asus Adaptive QOS. Classification based QOS is a never win situation and Asus classification lacks success with basic applications like Youtube when run in Chrome Browser. Building on top of this deficient foundation and then providing insufficient packet exposure leaves a lot to desire.

As I stated, I beat up bandwidth limiting and I experienced no video buffering, voice stutter, and a Triple A+ grade from DSLReports speed test, even when loading the link to capacity. This is the same test results I had with Cake. I was presently surprised.

Try it...

Morris

 

[Morris]

I'm now in agreement with all that state that Trend Micro is causing the snaps. They started again after I enabled Trend Micro. I can live without it. I'm also going to reinstall cake-qos as I'd rather have it than a guess that bandwidth limiting will keep real time apps running smoothly under load.

 

[randomName]

If anyone is using skynet they can block TM from calling home. These addresses blocked their Signature from updating since it wasn't routing my traffic properly since the default signature after a full reset.

fbsv1.trendmicro.com
fbsv2.trendmicro.com
ntd-asus-2014b-en.fbs20.trendmicro.com
gslb1.fbs.trendmicro.com.akadns.net
rgom10-en.url.trendmicro.com
trendmicro.com.edgesuite.net
slb1.fbs.trendmicro.com.akadns.net
activeupdate.trendmicro.co.jp
backup21.url.trendmicro.com
wrs.trendmicro.com
e5110.dscd.akamaiedge.net
dlcdnets.asus.com
wideip-dlcdnets.isoi.asia
dlcdnets-ds.asus.com.edgekey.net

 

[brummygit]

I have a similar setup, but 1 Floodlight Cam and the Doorbell 2 connect to an AP (AC-68U) - but I have some other IOT devices also connected to this AP, but their bandwidth is minimal. The other Floodlight Cam connects directly to the Router (AX-88U).

My battery powered (but connected to mains) Doorbell 2 is almost flawless, but the two mains powered Floodlight Cams have same issue of not starting live view. Seems the common thread here with the Ring Cameras are the ones that are mains powered seems to have issues.

I'm hoping the "nonat" permanently fixes the main issue for me with the Floodlight Cams, which was no live view. This happened whether on the same network, or roaming from my cell phone.

I've been doing some more testing and I think I have made some progress. My config is as follows:

• Ring Doorbell Pro
• RT-AX88U main router with wired connection to downstream RT-AC68U providing dedicated network for the Ring
• RT-AC68U set up in routing mode with NAT DISABLED, 5Ghz WiFi only on a clear channel group, IGMP Snooping enabled
• Upstream ISP Router from Sky in the UK resulting in Double NAT (nothing I can do about this) but RT-AX88U is in DMZ
• RT-AX88U in Symetric NAT mode, SIP Helper Disabled, Multicast Routing enabled in IPTV settings
• Cake configured - 50/10, triple-isolate, Diffserv4 (don't think this is important), nowash (don't think this is important), Regional (don't think this is important)
• Cake nat is on for me and doesn't seem to affect the results
• Cake no-ack-filter is set on both upload and download - this seems to improve things

Before today I could intermittently use Live View with poor reliability and better performance from 4G than on my home wifi. When motion was detected Live View wouldn't start while the doorbell was capturing the motion clip.

Today I tried the 'nonat' option which doesn't seem to affect me, but what does seem to have made a difference is turning off ack-filtering which I previously had active on my upload only. Live View now seems to start quickly and I can view the doorbell when I receive a motion alert.

At the moment (and it's too early to be sure) it seems that my Ring Doorbell Pro is now behaving properly with cake-qos. I plan to leave this configuration in place for a few days and if everything remains as good as it is now I will start to reverse some of the settings I don't think are having an influence. The Nat Passthrough SIP Helper setting will be one of the last as I know Ring use SIP and I think this helped me get some form of functionality in the first instance.

 

[dodge]

As I stated, I beat up bandwidth limiting and I experienced no video buffering, voice stutter, and a Triple A+ grade from DSLReports speed test, even when loading the link to capacity. This is the same test results I had with Cake. I was presently surprised.

Just tried this, and yes it works quite well! I still get A's for Bufferbloat like Cake, and it's not "3rd party" per say. Will monitor over the next few days.

EDIT : I'll take that back about 3rd-party, as ASUS QoS uses TM. Maybe I'll use Cake after all.

 

[Yooshaw]

I've been doing some more testing and I think I have made some progress. My config is as follows:

• Ring Doorbell Pro
• RT-AX88U main router with wired connection to downstream RT-AC68U providing dedicated network for the Ring
• RT-AC68U set up in routing mode with NAT DISABLED, 5Ghz WiFi only on a clear channel group, IGMP Snooping enabled
• Upstream ISP Router from Sky in the UK resulting in Double NAT (nothing I can do about this) but RT-AX88U is in DMZ
• RT-AX88U in Symetric NAT mode, SIP Helper Disabled, Multicast Routing enabled in IPTV settings
• Cake configured - 50/10, triple-isolate, Diffserv4 (don't think this is important), nowash (don't think this is important), Regional (don't think this is important)
• Cake nat is on for me and doesn't seem to affect the results
• Cake no-ack-filter is set on both upload and download - this seems to improve things

Before today I could intermittently use Live View with poor reliability and better performance from 4G than on my home wifi. When motion was detected Live View wouldn't start while the doorbell was capturing the motion clip.

Today I tried the 'nonat' option which doesn't seem to affect me, but what does seem to have made a difference is turning off ack-filtering which I previously had active on my upload only. Live View now seems to start quickly and I can view the doorbell when I receive a motion alert.

At the moment (and it's too early to be sure) it seems that my Ring Doorbell Pro is now behaving properly with cake-qos. I plan to leave this configuration in place for a few days and if everything remains as good as it is now I will start to reverse some of the settings I don't think are having an influence. The Nat Passthrough SIP Helper setting will be one of the last as I know Ring use SIP and I think this helped me get some form of functionality in the first instance.

Alas, the nonat option for me was temporary. It's hit or miss now. Will try no-ack-filter and report back.

We have a very similar setup, but my 68U is in AP mode, letting the 88U do all the routing work. Any reason you have your 68U doing routing (just curios - seems more complex)

 

[Morris]

Just tried this, and yes it works quite well! I still get A's for Bufferbloat like Cake, and it's not "3rd party" per say. Will monitor over the next few days.

EDIT : I'll take that back about 3rd-party, as ASUS QoS uses TM. Maybe I'll use Cake after all.

Yes it dose and I had the snaps show up again though I'm not shore if I had done a reboot of my router after removing cake. I suspect there were leftovers from Cake that caused this. I need to leave things along long enough to be confident that my current configuration is stable and also not mess my family up with a restart.

Morris

 

[brummygit]

Any reason you have your 68U doing routing (just curios - seems more complex)

Just to create a separate broadcast domain to reduce noise levels for the Ring device on the network.
I’ll be trying to get back to sharing my main WiFi SSID and subnet if things stay positive with this cake configuration.

 

[heysoundude]

I've been doing some more testing and I think I have made some progress. My config is as follows:

• Ring Doorbell Pro
• RT-AX88U main router with wired connection to downstream RT-AC68U providing dedicated network for the Ring
• RT-AC68U set up in routing mode with NAT DISABLED, 5Ghz WiFi only on a clear channel group, IGMP Snooping enabled
• Upstream ISP Router from Sky in the UK resulting in Double NAT (nothing I can do about this) but RT-AX88U is in DMZ
• RT-AX88U in Symetric NAT mode, SIP Helper Disabled, Multicast Routing enabled in IPTV settings
• Cake configured - 50/10, triple-isolate, Diffserv4 (don't think this is important), nowash (don't think this is important), Regional (don't think this is important)
• Cake nat is on for me and doesn't seem to affect the results
• Cake no-ack-filter is set on both upload and download - this seems to improve things

Before today I could intermittently use Live View with poor reliability and better performance from 4G than on my home wifi. When motion was detected Live View wouldn't start while the doorbell was capturing the motion clip.

Today I tried the 'nonat' option which doesn't seem to affect me, but what does seem to have made a difference is turning off ack-filtering which I previously had active on my upload only. Live View now seems to start quickly and I can view the doorbell when I receive a motion alert.

At the moment (and it's too early to be sure) it seems that my Ring Doorbell Pro is now behaving properly with cake-qos. I plan to leave this configuration in place for a few days and if everything remains as good as it is now I will start to reverse some of the settings I don't think are having an influence. The Nat Passthrough SIP Helper setting will be one of the last as I know Ring use SIP and I think this helped me get some form of functionality in the first instance.

You and I share connection speeds, and I'm finding my best result with zeros set in cake for speed. the ISP is already throttling us; let's not throttle ourselves as well. YMMV.
as to rtt regional not being important, my experience is: my packet loss has flatlined at zero since I made the change (but I'm also besteffort, aggressive ack, dual-XXXhost) and I'm seeing within 1-2% of the speeds I pay for from my ISP. Again, YMMV. Part of me suspects if your pings are at or below mine (7-8ms) you could set rtt at metro, but as I have but one connection to test, I must rely on similarly brave experimentation by cake users who comment on here to verify/refute my results

 

[brummygit]

You and I share connection speeds, and I'm finding my best result with zeros set in cake for speed. the ISP is already throttling us; let's not throttle ourselves as well. YMMV.
as to rtt regional not being important, my experience is: my packet loss has flatlined at zero since I made the change (but I'm also besteffort, aggressive ack, dual-XXXhost) and I'm seeing within 1-2% of the speeds I pay for from my ISP. Again, YMMV. Part of me suspects if your pings are at or below mine (7-8ms) you could set rtt at metro, but as I have but one connection to test, I must rely on similarly brave experimentation by cake users who comment on here to verify/refute my results

That's interesting. I have wondered for a while whether I should set a limit on my download or just rely on unlimited as I'm the wrong side of the choke point really. I have been running in the current configuration for a few days now and whilst it's much more reliable, I am still seeing Live View slow to start from time to time. I've just changed my download to unlimited and will run like that for a while, then I will assess whether to have another try with unlimited on upload too - my experience wasn't as conclusive as others saw in previous tests.

Your experience with aggressive ack-filtering is also making me think. If I'm experiencing high packet loss, filtering out acks would just exacerbate the problem resulting in more retransmits. Maybe turning off ack-filter may be masking the real issue. My pings are usually around 10-15ms.

 

[heysoundude]

That's interesting. I have wondered for a while whether I should set a limit on my download or just rely on unlimited as I'm the wrong side of the choke point really. I have been running in the current configuration for a few days now and whilst it's much more reliable, I am still seeing Live View slow to start from time to time. I've just changed my download to unlimited and will run like that for a while, then I will assess whether to have another try with unlimited on upload too - my experience wasn't as conclusive as others saw in previous tests.

Your experience with aggressive ack-filtering is also making me think. If I'm experiencing high packet loss, filtering out acks would just exacerbate the problem resulting in more retransmits. Maybe turning off ack-filter may be masking the real issue. My pings are usually around 10-15ms.

Take a whack at the acks and see if your experience is comparable to mine...choke point being the ISP is exactly right - for those of us below 100Mbps or so, setting speed limits in cake are a waste of time by my logic and so far in unscientific (experiential) "testing" (It's also a sticking point for me that the copper phone infrastructure seems more capable than they're letting us have access to (for data) but I'll save that rant for another time/place).

I've just looked at my "quality" aka packet loss according to connmon - one instance of 3% loss today, and I have no recollection about what was going on at the time - BUT since upgrading from 384.18 and the reboot, I've been assigned a new WAN IP by my ISP with ping up in the 30ms range, but jitter has dropped to below 1ms, so I'm testing my rtt setting theory. Speeds have dropped a smidge too, but nothing worth making an issue over (I'm REALLY looking forward to having all of this data on one page to take to my ISP @Jack Yaz ) - the ping issue is clearly impacting my unbound DNS times, and that's not cool.

ASIDE - <an overlooked part of all of this is the stability of the time source the clock(s) in our routers reference - for data to flow smoothly bidirectionally, without a good reference clock (NTP sync - I prefer individual clocks to pool options) for the router's processors to make the right containers get filled appropriately and sent to/received from the right places at the correct time interval - the rest of this is spitting into the wind. I trust that everyone doing the coding is mindful if not conscientious about this, so any issues in this regard are config or plain old hardware limitations. If you're not using the ntp referencing built into the firmware, get that sorted and watch how things change on your network>

 

[Wade Coxon]

ASIDE - <an overlooked part of all of this is the stability of the time source the clock(s) in our routers reference - for data to flow smoothly bidirectionally, without a good reference clock (NTP sync - I prefer individual clocks to pool options) for the router's processors to make the right containers get filled appropriately and sent to/received from the right places at the correct time interval - the rest of this is spitting into the wind. I trust that everyone doing the coding is mindful if not conscientious about this, so any issues in this regard are config or plain old hardware limitations. If you're not using the ntp referencing built into the firmware, get that sorted and watch how things change on your network>

The clock stability that is important to cake and QoS in genera is not really down to the NTP sync side of things. The clock stability we are talking about is down to the router's internal timekeeping (ie. the stability of its crystal). NTP only checks for sync to external sources once every few minutes, which has no bearing on timing round trip delays on packets. Good NTP algorithms will maintain a generalised clock drift value which is used to compensate for an internal clock that is inherently gaining or losing time, but even that compensation mechanism wouldn't be useful for delay measurement. NTP is for time-of-day stuff, not time-between-events stuff.

 

[heysoundude]

Just a field report - from their silence, users seem quite pleased of late. not sure if it's because of the cake-qos tweaking (to rtt metro setting - 10ms, because connmon tells me 7.xxx is what's happening) or my IPv6 tweaking or making some space in 2.4GHz wifi, or all of that and the update to Merlin 384.19, but its quick and smooth and stable.

 

[brummygit]

It certainly runs well on my own network - I am running with rtt set to regional which seems to work well for me.

My main concerns are around the longevity of this solution as we only have a couple of supported routers and I don't know if anyone is watching for updates to the underlying cake code. Unfortunately I'm not in a position to do more to help.

 

[heysoundude]

It certainly runs well on my own network - I am running with rtt set to regional which seems to work well for me.

My main concerns are around the longevity of this solution as we only have a couple of supported routers and I don't know if anyone is watching for updates to the underlying cake code. Unfortunately I'm not in a position to do more to help.

rtt settings - I've found that the closer they're set to what connmon reports for ping time, the snappier my network is.

Longevity - I'm not sure the underlying code is still being actively worked on or updated...or needs to be. (someone would have to keep an eye on the git, I suppose)
That said - I'd wager that where it is now will work for some time to come, as the supported routers are the foundation to where Asus seems to be headed. Check out the specs of the AX86 - basically the same as the AX88; when WiFi6e versions of these start to come down the pipe, I suspect that it will just be the radios that are different until there's a significant mobo/processor update (and I really hope we get 2GB or more RAM - if RasPis can do it for under $100...) The good news is Merlin is already working on v386

 

[BenK_Oz]

hey guys im running cake on an rt-ac86u,
We have multiple people in the house running video conference streams, and weve been getting a bit of lag in them since i installed cake instead of the asus QoS. not sure if its a change in my isp or if its cake (only been installed for a week or so). Has there been any reports of this?
is there anything i can do to test out the settings? is there a better place to ask these questions ? thanks! and sorry if this is the wrong spot

 

[ttgapers]

hey guys im running cake on an rt-ac86u,
We have multiple people in the house running video conference streams, and weve been getting a bit of lag in them since i installed cake instead of the asus QoS. not sure if its a change in my isp or if its cake (only been installed for a week or so). Has there been any reports of this?
is there anything i can do to test out the settings? is there a better place to ask these questions ? thanks! and sorry if this is the wrong spot

Would have to look at some of your stats (especially under load), tied to your configuration. I've been absent due to work/fam commitments over the last month, so venturing back into the waters a bit. Glad to see the team keeping this going!

For now:
1. Your ISP/connection(s) details as advertised
2. Your Cake configuration