What's new

CakeQOS CakeQOS-Merlin

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

I might be off the mark, but from what I understand, setting the RTT lower will mean that Cake can clamp down on packets faster when you are hitting your bandwidth limit. It allows it to act faster as it is expecting the packet acks much sooner.

I also believe that you need to set the RTT to a value that is somewhere around the average ping to the Internet services you are accessing, not the first hop. The packet round trip is measured out to the destination, not your first hop, so in order to guesstimate when to expect replies for your traffic, the round total round trip must be accounted for.

Reading the docs seems to suggest that cake self tunes the RTT pretty well, so getting it in the balllpark is good enough. The default value of 100ms should be fine for most cases. You may consider "Regional" (30ms) if you are mostly accessing local game or streaming servers or something like that. I wouldn't go any lower unless you had very good reason to though.

Cake is about preventing a log jam on the interfaces of your router and the one it connects to. Keep it simple and only adjust the bandwidth parameters. When you lower them sufficiently, they prevent the interfaces from being a bottle neck. Increasing RTT will have the same effect as lowering bandwidht. By adjusting multiple parameters you are simply making it harder to understand the effects of your changes.

Cake can not fix upstream bottlenecks. The best fix for this is a good ISP if one is available.

Morris
 
Increasing RTT will have the same effect as lowering bandwidht. By adjusting multiple parameters you are simply making it harder to understand the effects of your changes.
Other way around. An overly aggressive RTT will have a negative effect and lower your effective throughput. Unless I misinterpreted what you were trying to say there?

I agree in that for 90% of cases, adjusting RTT will not be of any use.

However, once the bandwidth is dialled in well, there isn't any harm in having a bit of a play with tuning in the RTT parameter for the adventurous. As I said earlier, I wouldn't think anyone will see any benefit from adjusting below "regional" though.

At the end of the day, it is a way of telling the cake algorithms what "Round Trip Time" to expect on any packets it is sending and receiving to remote servers. If you provide a value that is as close to the average ping to the servers you most care about, then the algorithm will have the best information with which to work with.
 
I've recorded a few videos of the problems I'm seeing:

Default settings with bandwidth set at less than 90%.
https://streamable.com/37lrsa

Default settings with bandwidth set at less than 90% & 'conservative' overhead.

Default settings with bandwidth set at less than 90%, 'conservative' overhead and 55 ms RTT https://streamable.com/xsmxbv

It's the massive lag spikes that are incompatible with online gaming.
 
Last edited:
I've recorded a few videos of the problems I'm seeing:
...
It's the massive lag spikes that are incompatible with online gaming.
No real problem there. You will naturally get those spikes when the link is being saturated. The algorithm can't respond instantly. If you need to avoid all spikes, you need a QoS solution that reserves a minimum fixed amount of bandwidth for your priority devices.

Also, you cut off the end of the last video too quickly and we didn't get to see the stats!! :)

Since you have a 10:1 ratio on your upload/download, you may also want to consider enabling ack-filter.
 
Page 1 updated for:

1.0.7
  • GT-AC2900 & RT-AX86U support (Experimental)
1.0.6
  • Apply archer instead of runner

Thanks as usual to @Adamm as well as @dave14305 and others contributing to these releases especially around device testing (@jata) and Cake support for additional models (@Odkrys)!
 
Last edited:


Hi @Odkrys

We are hoping you can assist us around collab on understanding the build process/updates/new model support etc. @Adamm has an open issue here in regard to recompile of Cake/TC. Would appreciate your input if/when you have some time. Thanks again for this additional build!
 
On another note, in the original thread that got Cake-QOS going there was a teased GUI screenshot from a user @robcore who we haven't seen around these parts for some time. Here was his screenshot:

1607449961124.png


  1. Not suggesting the placement (prob better in Addons - since we disable native QoS), but for the simplicity of Cake (up/down/besteffort) defaults, are there any GUI devs out there? @Adamm - I trust this is something (with zero priority - more nice to have).
  2. Would it assist in also eventually getting to amtm as well?
  3. Would users appreciate this and help in driving adoption some more as we get additional models onboarded?
Thoughts?
 
On another note, in the original thread that got Cake-QOS going there was a teased GUI screenshot from a user @robcore who we haven't seen around these parts for some time. Here was his screenshot:

View attachment 28344

  1. Not suggesting the placement (prob better in Addons - since we disable native QoS), but for the simplicity of Cake (up/down/besteffort) defaults, are there any GUI devs out there? @Adamm - I trust this is something (with zero priority - more nice to have).
  2. Would it assist in also eventually getting to amtm as well?
  3. Would users appreciate this and help in driving adoption some more as we get additional models onboarded?
Thoughts?
I was looking at the SQM screens in my OpenWRT installation on Raspberry Pi. It's quite dull, but could be done.
 
I've recorded a few videos of the problems I'm seeing:

Default settings with bandwidth set at less than 90%.
https://streamable.com/37lrsa

Default settings with bandwidth set at less than 90% & 'conservative' overhead.

Default settings with bandwidth set at less than 90%, 'conservative' overhead and 55 ms RTT https://streamable.com/xsmxbv

It's the massive lag spikes that are incompatible with online gaming.

You do not have a buffer bloat problem as your scores are all A and/or A+
 
I was looking at the SQM screens in my OpenWRT installation on Raspberry Pi. It's quite dull, but could be done.
@dave14305....maybe you can bring some of that Flex magic to Cake!!!! ;)
 
I was looking at the SQM screens in my OpenWRT installation on Raspberry Pi. It's quite dull, but could be done.

Hi I am game for your thoughts/input. I can get an Enhancement/Issue opened and thus the collab between @Adamm and co. Thanks for the quick reply.
 
You do not have a buffer bloat problem as your scores are all A and/or A+

Hi Morris,

I suspect that the buffer bloat score is based upon an average buffer bloat delay and not the maximum variance in ping.

If you watch the videos you can see major spikes in the buffer bloat - e.g. 350ms. I think I once read a Cisco VOIP document that stated the maximum 'functional' jitter that can be accommodated is 300ms - and that has to be accounted for in the network/voice config. When online gaming, it results in the game stuttering and player actions being 'reversed' - e.g. you're running towards a door and suddenly you're back in the centre of the room. If this happens more than once or twice every 30 minutes, the game is effectively unplayable.

I think this may have been what Askan7 was experiencing with earlier versions of CakeQoS.

https://www.snbforums.com/search/75009/

I appreciate the effort and time that everybody is putting into a working QoS solution, but it seems that the most time sensitive applications (e.g. gaming and VOIP) aren't quite getting the rock solid connections that they need.

FlexQoS (1.04) was awesome when I first installed it and managed to eliminate the lag spikes associated with my wife watching Netflix (Netflix on Roku appears to download a large chunk of data every 10-15 seconds, rather than a constant stream of media). More recently (1.05 & 1.06), it was prone to large lag spikes (500ms that would last for 20+ seconds), games freezing, being kicked from servers because the 'connection dropped', etc. DNS requests also seemed to be very slow and web pages would be very sluggish. This would happen after my wife was in bed and the connection had almost zero traffic. I helped a friend install FlexQoS and he also experienced the same issues - great at first and not so great now. I don't know if Dave actually changed anything in the backend between releases, but that's what we've experienced as (freeloading) end users.

I really want to emphasise that I do appreciate all the work everybody is putting into this code and I'm trying to be constructive in my feedback. Are there any logs that I could provide you guys to help investigate these niggling issues?
 
Hi Morris,

I suspect that the buffer bloat score is based upon an average buffer bloat delay and not the maximum variance in ping.

If you watch the videos you can see major spikes in the buffer bloat - e.g. 350ms. I think I once read a Cisco VOIP document that stated the maximum 'functional' jitter that can be accommodated is 300ms - and that has to be accounted for in the network/voice config. When online gaming, it results in the game stuttering and player actions being 'reversed' - e.g. you're running towards a door and suddenly you're back in the centre of the room. If this happens more than once or twice every 30 minutes, the game is effectively unplayable.

I think this may have been what Askan7 was experiencing with earlier versions of CakeQoS.

https://www.snbforums.com/search/75009/

I appreciate the effort and time that everybody is putting into a working QoS solution, but it seems that the most time sensitive applications (e.g. gaming and VOIP) aren't quite getting the rock solid connections that they need.

FlexQoS (1.04) was awesome when I first installed it and managed to eliminate the lag spikes associated with my wife watching Netflix (Netflix on Roku appears to download a large chunk of data every 10-15 seconds, rather than a constant stream of media). More recently (1.05 & 1.06), it was prone to large lag spikes (500ms that would last for 20+ seconds), games freezing, being kicked from servers because the 'connection dropped', etc. DNS requests also seemed to be very slow and web pages would be very sluggish. This would happen after my wife was in bed and the connection had almost zero traffic. I helped a friend install FlexQoS and he also experienced the same issues - great at first and not so great now. I don't know if Dave actually changed anything in the backend between releases, but that's what we've experienced as (freeloading) end users.

I really want to emphasise that I do appreciate all the work everybody is putting into this code and I'm trying to be constructive in my feedback. Are there any logs that I could provide you guys to help investigate these niggling issues?

I had a quick look through your posts and I suspect you are getting throttled by your ISP. If you have done lots of tweaking in CakeQOS, you can always record and revert back to the "defaults" and re-run your bloat tests. if you are using a tool like connmon I would also suggest looking at historical stats to see how "clean" your circuit is. I've been using Cake using defaults on my cable connection heavy UHD, VOIP but no gaming so can't comment there.
 
What is the relationship between the RTT commands and buffer bloat? I've experimented with different values and setting the RTT to a lower value negatively impacts the bandwidth.

Somebody suggested the RTT should be set to match the first hop ping to my ISP:

traceroute to virginmedia.com (213.105.9.24), 30 hops max, 38 byte packets
1 10.53.35.89 (10.53.35.89) 8.958 ms 11.531 ms 10.845 ms
2 croy-core-2a-xe-700-0.network.virginmedia.net (62.252.14.33) 9.940 ms 12.8

This reduces my download speed from 380Mbps to 216Mbps. This online test claims that my result is A+, but the buffer bloat is 280ms?

View attachment 28334

View attachment 28336

Are there any benefits to reducing the RTT in Cake QoS?

No matter what settings I'm trying, I still seem to be suffering from some buffer bloat and some quite large spikes in buffer bloat - e.g. jumps from 6ms to 300 ms during the test.

My main reason for wanting a working QoS solution is online gaming. I'm after a low and stable ping with no discernible spikes - i.e. I see on my screen, what is actually happening in the game. It is also important that when I click fire, the other person dies. I'm willing to sacrifice a bit of bandwidth to achieve this, but I'm struggling to see any improvements.

You do not have a buffer bloat problem as your scores are all A and/or A+

right. but remember they're a virtually bloodthirsty murderer/gunperson online, where a microsecond of latency could mean the difference between monetizing their twitch or toiling away in obscurity.

(the really cranky, fistshaking, get-off-my-lawn old guy in me wants to suggest that if gamers want to recreationally shed blood, they should take up jousting or revive the practice of showdowns at high noon)

Sarcasm aside, what needs better dissemination is that the latency involved in online gaming can only be mitigated to a point when playing through a server neither end of the competition controls. Further: sheer speed doesn't make up for the inherent time it takes for data to traverse the global interwebs, and local computers on each end to react at anywhere near the degree of real-time sync that they seem to expect.
 
Good morning all. I am trying to set my download to unlimited. From what I read, from the cake-qos script, I would choose change setup->enter download speed and just type "unlimited".

When I exit the script, and go back into the script and check on existing setting, nothing has changed (the old values are still there).

Does the config file need to be edited directly for unlimited?
 
remember they're a virtually bloodthirsty murderer/gunperson online, where a microsecond of latency could mean the difference between monetizing their twitch or toiling away in obscurity.

I'm a casual, but keen gamer. It's just very frustrating when the connection is less than optimal. Before I upgraded my router, it was impossible to game when anybody was streaming media in the house. Things are definitely improved, but are still a bit glitchy.

sheer speed doesn't make up for the inherent time it takes for data to traverse the global interwebs, and local computers on each end to react at anywhere near the degree of real-time sync that they seem to expect.

I'm not sure that is valid. The base ping is well within the limits for good online gaming. The servers and gaming PC's are clearly able to handle the data because they run smooth as butter without QoS enabled, if there is no other local network traffic - e.g. after my wife has gone to bed.

The problem appears to be one of traffic prioritisation - gaming data should definitely be marked as EF. Is Dave's Learning From Home 'catch all bucket' accidentally hoovering up the wrong traffic and marking it with the lowest priority?
 
Hi Morris,

I suspect that the buffer bloat score is based upon an average buffer bloat delay and not the maximum variance in ping.

If you watch the videos you can see major spikes in the buffer bloat - e.g. 350ms. I think I once read a Cisco VOIP document that stated the maximum 'functional' jitter that can be accommodated is 300ms - and that has to be accounted for in the network/voice config. When online gaming, it results in the game stuttering and player actions being 'reversed' - e.g. you're running towards a door and suddenly you're back in the centre of the room. If this happens more than once or twice every 30 minutes, the game is effectively unplayable.

I think this may have been what Askan7 was experiencing with earlier versions of CakeQoS.

https://www.snbforums.com/search/75009/

I appreciate the effort and time that everybody is putting into a working QoS solution, but it seems that the most time sensitive applications (e.g. gaming and VOIP) aren't quite getting the rock solid connections that they need.

FlexQoS (1.04) was awesome when I first installed it and managed to eliminate the lag spikes associated with my wife watching Netflix (Netflix on Roku appears to download a large chunk of data every 10-15 seconds, rather than a constant stream of media). More recently (1.05 & 1.06), it was prone to large lag spikes (500ms that would last for 20+ seconds), games freezing, being kicked from servers because the 'connection dropped', etc. DNS requests also seemed to be very slow and web pages would be very sluggish. This would happen after my wife was in bed and the connection had almost zero traffic. I helped a friend install FlexQoS and he also experienced the same issues - great at first and not so great now. I don't know if Dave actually changed anything in the backend between releases, but that's what we've experienced as (freeloading) end users.

I really want to emphasise that I do appreciate all the work everybody is putting into this code and I'm trying to be constructive in my feedback. Are there any logs that I could provide you guys to help investigate these niggling issues?


I've been using cake now, for me it's better than FlexQos for gaming and voip. But I agree with you, there's still some issues, I still get noticeable lag while gaming under a few scenarios. Rubber banding and bad hit reg that is.
I'm starting to think this is might be related to broadcom closed source drivers as I know people with edge routers using cake getting near perfect results.

Again It's still a big improvement, I literally couldn't play as soon as some download/upload started without SQM/QOS. Also I play shooters on competitive settings at very high frame rates, any sort of lag bothers me.
 
Last edited:

Latest threads

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top