Hi everyone
I just shifted from flex to cake to give it a try
In flex, i always set overhead at 39
Now I've set following settings in cake, does this look fine?
I've FTTH GPON connection, actual speed reports from speed test at 38.5/39.5 at any given time of the day/night, isp connection designed at 40/40 , isp modem in bridge mode
Suggestions needed please?
I am in the UK with TalkTalk Fibre on the 67Mbps package. So, essentially vdsl2.
Running RT-AX88U with a Draytek Vigor 130 as a modem.
Currently getting about 50Mbps/10Mbps DL/UL speeds.
1) What cake-cos settings do you recommend to start with?
2) Should I specify the same settings on both download and upload?
Any help would be much appreciated?
I am planning to install in the morning (when the network is quiet and complaints from the family can be avoided) and have a question around overheads
I am connected to Sky Broadband in the UK (80/20) VDSL2 using a Vigor 130 modem (1483 Bridged IP LLC) connected to the AX88U and using DHCP option 61 to connect. Should I treat this as pppoe-ptm or does having the modem first mean I should be using a different overhead setting.
I am in the UK with TalkTalk Fibre on the 67Mbps package. So, essentially vdsl2.
Running RT-AX88U with a Draytek Vigor 130 as a modem.
Currently getting about 50Mbps/10Mbps DL/UL speeds.
1) What cake-cos settings do you recommend to start with?
2) Should I specify the same settings on both download and upload?
Any help would be much appreciated?
Have a play around and see what seems to work well when you're downloading big files or streaming/gaming since there are subtleties. It should be an exact science, but it's really not and everyone's got different circumstances.
For my part:
In the end, I found little to no benefit setting speed caps directly. The download speed is for sure being capped on talktalk's end as the line is capable of 90+mbps (I saw this while performing modem tweaks when I used to have a d7000 with ancistrus' opensource tweaks on it) and it fluctuates a fair bit on my end throughout the day, meaning setting it 65 meant either missing out on a good 1MBps+ at the best of times and causing issues if the speed dropped to 60mbps or lower anyway. Capping the upload does help reduce bufferbloat on its own, as the data below does show, but the results didn't seem worth it when making use of it in practicality. It's like, you pay for 20mbps, you get 18, but does the drop in standard dev of latency for upload outweigh dropping that 16? You'll have to judge on your end
For this 'form' of cake we're dealing with, diffserv4 is about the same as just besteffort and diffserv8 is for sure no better than diffserv4 since it's not capable of doing that much classification. I just stuck with diffserv4 on the offchance something manages to get put into a more appropriate bucket but I don't bank on it lol It's like being given the option of gradually more flashy cars but you only have a licence to drive a tractor lol
You'll need nowash to help with any classification that could happen.
There was a great reddit thread posted here which mentions that so long as you have the overhead in the right ballpark, it doesn't matter too much about overhead calculations. Perhaps they should be higher, perhaps they could be lower. I read through a lot of conflicting sources, some suggesting ethernet, others docsis depending on the focus of the connection, but if the specialist says 'ballpark is fine', then I wouldn't worry about it at the end of the day
Because we have such a highish ratio between download and upload, some form of ackfiltering is supposed to be beneficial. I've seen '10:1', some places much higher like 20:1. We're 4:1 but I've noticed it does help a bit (try with and without). There's aggressive ackfiltering too but that reddit thread suggested it should never have been made! It's at least worth considering over those who have more symmetric lines (1:1 up and down).
Finally, and this was just playing around...try setting 'regional' for the download. That had a massive impact on performance - it does cost some speed but you can really feel the difference from it. I tried it on upload too for the hell of it and have just stuck with it. It's probably messing with something important and I don't understand a lot of the implications, I will be tweaking the rtt more finely in future tweaking - however - if it is linked to ping, of which mine is always <30ms, this setting sets a roundtrip time of 30ms. See what you think; I think it's very impressive considering the kernel limitations.
I can't remember why I moved away from dst-host and src-host but I think it's because they're already being done on both (+ more besides). Coffee in the morning might spur some additions to these ramblings! Hope there's something useful here.
Background data from some old tests:
I found through latency testing that without setting any download or upload speed caps, the download wasn't that jittery but upload was a bit.
I'll attach some of my old raw data: WITHOUT CAKE
/jffs/addons/util/betterspeedtest.sh -t 60 -H netperf-eu.bufferbloat.net
Testing against netperf-eu.bufferbloat.net (ipv4) with 5 simultaneous sessions while pinging gstatic.com (60 seconds in each direction)
............................................................
Download: 66.82 Mbps
Latency: (in msec, 60 pings, 0.00% packet loss)
Min: 16.453
10pct: 16.738
Median: 17.168
Avg: 17.593
90pct: 19.040
Max: 21.182
............................................................
Upload: 18.65 Mbps
Latency: (in msec, 60 pings, 0.00% packet loss)
Min: 16.811
10pct: 32.034
Median: 41.318
Avg: 40.131
90pct: 45.303
Max: 46.185
Have a play around and see what seems to work well when you're downloading big files or streaming/gaming since there are subtleties. It should be an exact science, but it's really not and everyone's got different circumstances.
For my part:
In the end, I found little to no benefit setting speed caps directly. The download speed is for sure being capped on talktalk's end as the line is capable of 90+mbps (I saw this while performing modem tweaks when I used to have a d7000 with ancistrus' opensource tweaks on it) and it fluctuates a fair bit on my end throughout the day, meaning setting it 65 meant either missing out on a good 1MBps+ at the best of times and causing issues if the speed dropped to 60mbps or lower anyway. Capping the upload does help reduce bufferbloat on its own, as the data below does show, but the results didn't seem worth it when making use of it in practicality. It's like, you pay for 20mbps, you get 18, but does the drop in standard dev of latency for upload outweigh dropping that 16? You'll have to judge on your end
For this 'form' of cake we're dealing with, diffserv4 is about the same as just besteffort and diffserv8 is for sure no better than diffserv4 since it's not capable of doing that much classification. I just stuck with diffserv4 on the offchance something manages to get put into a more appropriate bucket but I don't bank on it lol It's like being given the option of gradually more flashy cars but you only have a licence to drive a tractor lol
You'll need nowash to help with any classification that could happen.
There was a great reddit thread posted here which mentions that so long as you have the overhead in the right ballpark, it doesn't matter too much about overhead calculations. Perhaps they should be higher, perhaps they could be lower. I read through a lot of conflicting sources, some suggesting ethernet, others docsis depending on the focus of the connection, but if the specialist says 'ballpark is fine', then I wouldn't worry about it at the end of the day
Because we have such a highish ratio between download and upload, some form of ackfiltering is supposed to be beneficial. I've seen '10:1', some places much higher like 20:1. We're 4:1 but I've noticed it does help a bit (try with and without). There's aggressive ackfiltering too but that reddit thread suggested it should never have been made! It's at least worth considering over those who have more symmetric lines (1:1 up and down).
Finally, and this was just playing around...try setting 'regional' for the download. That had a massive impact on performance - it does cost some speed but you can really feel the difference from it. I tried it on upload too for the hell of it and have just stuck with it. It's probably messing with something important and I don't understand a lot of the implications, I will be tweaking the rtt more finely in future tweaking - however - if it is linked to ping, of which mine is always <30ms, this setting sets a roundtrip time of 30ms. See what you think; I think it's very impressive considering the kernel limitations.
I can't remember why I moved away from dst-host and src-host but I think it's because they're already being done on both (+ more besides). Coffee in the morning might spur some additions to these ramblings! Hope there's something useful here.
Background data from some old tests:
I found through latency testing that without setting any download or upload speed caps, the download wasn't that jittery but upload was a bit.
I'll attach some of my old raw data: WITHOUT CAKE
/jffs/addons/util/betterspeedtest.sh -t 60 -H netperf-eu.bufferbloat.net
Testing against netperf-eu.bufferbloat.net (ipv4) with 5 simultaneous sessions while pinging gstatic.com (60 seconds in each direction)
............................................................
Download: 66.82 Mbps
Latency: (in msec, 60 pings, 0.00% packet loss)
Min: 16.453
10pct: 16.738
Median: 17.168
Avg: 17.593
90pct: 19.040
Max: 21.182
............................................................
Upload: 18.65 Mbps
Latency: (in msec, 60 pings, 0.00% packet loss)
Min: 16.811
10pct: 32.034
Median: 41.318
Avg: 40.131
90pct: 45.303
Max: 46.185
Thanks for the detailed response. I will give all these a try.
On a totally separate note...
I'm pretty sure you are aware, but you can squeeze a bit more speed (both DL and UL) by tweaking the SNR on the Vigor 130.
This did not work on my prior BT connection, but definitely works on Talktalk.
My default SNR is 6db; and I have been reducing by 0.5db a week and so far the connection is very stable and going good. Managed to get an extra 6 Mbps so far. I was not getting above 45Mbps and now I easily get 50Mbps with a 3db SNR drop setting. I will keep going lower each week...
Thanks for the detailed response. I will give all these a try.
On a totally separate note...
I'm pretty sure you are aware, but you can squeeze a bit more speed (both DL and UL) by tweaking the SNR on the Vigor 130.
This did not work on my prior BT connection, but definitely works on Talktalk.
My default SNR is 6db; and I have been reducing by 0.5db a week and so far the connection is very stable and going good. Managed to get an extra 6 Mbps so far. I was not getting above 45Mbps and now I easily get 50Mbps with a 3db SNR drop setting. I will keep going lower each week...
I used to do adsl tweaks on our setup about 16 years ago it's been a while , the problem being 6dB now is about as good as it gets (back then in the early days for our broadband, we'd sometimes have 12 to play with!) - if you halve that to 3db, more often than not it would be fine for a couple of weeks and then randomly cut out and reestablish back at 6dB when you least expected it. I always hate how any drops in connection in quick succession (from tweaking, power outages or otherwise), can lead to being penalised onto a more stable (slower) connection til they bump you back. If I can turn my DL to higher than 80 I'd be interested in playing (perhaps to 4.5dB?), but I've grown used to these speeds and don't think I'd feel it unless it was 100+ or proper FTTP (a man can dream!)...could be fun to get back into that again!
Are those values you're getting from a speed test (ethernet cabled device to router to modem) or something else? Are they what your vigor is showing you cause mine usually shows ~76000 and 20000 kbps on the line?
I used to do adsl tweaks on our setup about 16 years ago it's been a while , the problem being 6dB now is about as good as it gets (back then in the early days for our broadband, we'd sometimes have 12 to play with!) - if you halve that to 3db, more often than not it would be fine for a couple of weeks and then randomly cut out and reestablish back at 6dB when you least expected it. I always hate how any drops in connection in quick succession (from tweaking, power outages or otherwise), can lead to being penalised onto a more stable (slower) connection til they bump you back. If I can turn my DL to higher than 80 I'd be interested in playing (perhaps to 4.5dB?), but I've grown used to these speeds and don't think I'd feel it unless it was 100+ or proper FTTP (a man can dream!)...could be fun to get back into that again!
Are those values you're getting from a speed test (ethernet cabled device to router to modem) or something else? Are they what your vigor is showing you cause mine usually shows ~76000 and 20000 kbps on the line?
Hi everyone
I just shifted from flex to cake to give it a try
In flex, i always set overhead at 39
Now I've set following settings in cake, does this look fine?
I've FTTH GPON connection, actual speed reports from speed test at 38.5/39.5 at any given time of the day/night, isp connection designed at 40/40 , isp modem in bridge mode
Suggestions needed please?
I have comcast advertise speeds of 100/5 mpbs. I tried the different options/speeds recommended here but eventually settled on using the "defaults" that kind of started everything for me. This is what I'm using below with about 20+ devices connected. I use a full-time VPN as well with 3 firesticks wireless and get no lag when watching live sports and HD movies/TV shows thru Kodi. The gaming devices (3) I have to do not get routed thru a VPN however. I have 1 xbox (wireless) and 1 PS4 (wireless) connected on the 3rd floor with no lag as well when playing CoD. I setup cake over a month ago and barely mess with the settings now as everything works without any issue. Using x3mRouting's VPN script for bypassing VPN is just icing on the "cake"!!!
how I installed it: Thank you very much! I also tried to use this scripts but was not able to get it working. Until now! I followed your lines and the first trail was working! I will try to use this for adjusting Cake. So with this I can adjust Cake not being physically there (via VPN...
I just tested mine doing a constant ping in one window and running a speed test in another. With cake turned off i would get dropped packets in the ping and fastest speedtest result., i then tested using various values with cake on to see what got me the best speedtest result with no dropouts
I used to do adsl tweaks on our setup about 16 years ago it's been a while , the problem being 6dB now is about as good as it gets (back then in the early days for our broadband, we'd sometimes have 12 to play with!) - if you halve that to 3db, more often than not it would be fine for a couple of weeks and then randomly cut out and reestablish back at 6dB when you least expected it. I always hate how any drops in connection in quick succession (from tweaking, power outages or otherwise), can lead to being penalised onto a more stable (slower) connection til they bump you back. If I can turn my DL to higher than 80 I'd be interested in playing (perhaps to 4.5dB?), but I've grown used to these speeds and don't think I'd feel it unless it was 100+ or proper FTTP (a man can dream!)...could be fun to get back into that again!
Are those values you're getting from a speed test (ethernet cabled device to router to modem) or something else? Are they what your vigor is showing you cause mine usually shows ~76000 and 20000 kbps on the line?
4.5dB will likely get you very close to your purchased speed (can it be adjusted in 0.1dB increments?) if not somewhat above, but as you say, it's a trade-off in reliability of connection. that setting is obviously (to me- I deal with these types of voltage gates for my day job - see my u/name) the ducking ratio of a fixed threshold downward expander circuit, so if the signal drops below 4.5dB above the noise on the line, Whammo, it shuts the door and cuts off your connection; what would be best to adjust is the threshold itself, and then the ducking ratio - 3dB can be rather huge if the threshold is set correctly. attack should be on the conservative side (so to not overreact), release somewhat less so (for a more rapid recovery). How deep into those will the firmware of the gateway allow you?
Finally, and this was just playing around...try setting 'regional' for the download. That had a massive impact on performance - it does cost some speed but you can really feel the difference from it. I tried it on upload too for the hell of it and have just stuck with it. It's probably messing with something important and I don't understand a lot of the implications, I will be tweaking the rtt more finely in future tweaking - however - if it is linked to ping, of which mine is always <30ms, this setting sets a roundtrip time of 30ms. See what you think; I think it's very impressive considering the kernel limitations.
I believe the rtt setting in cake is another tuning parameter, similar to aligning overhead with the MTU your ISP uses, and similarly important to its correct/intended functioning:
when I changed mine to more closely reflect pings to their server (metro, 10ms because I reliably ping in the 7-8ms range), my ac86 calmed right down and sped right up - jitter went below 0.2ms, packet loss all but disappeared, upload stabilised at slightly above purchased speed (download still varies according to load/demand, which is as it should be, but can occasionally tick above purchased speeds in low/no load conditions).
(Now that I've seen a gateway that can be configured to tune the filter on the line, I suspect my connection can be made to give me more, if I can find how to access the tuning parameters...)
4.5dB will likely get you very close to your purchased speed (can it be adjusted in 0.1dB increments?) if not somewhat above, but as you say, it's a trade-off in reliability of connection. that setting is obviously (to me- I deal with these types of voltage gates for my day job - see my u/name) the ducking ratio of a fixed threshold downward expander circuit, so if the signal drops below 4.5dB above the noise on the line, Whammo, it shuts the door and cuts off your connection; what would be best to adjust is the threshold itself, and then the ducking ratio - 3dB can be rather huge if the threshold is set correctly. attack should be on the conservative side (so to not overreact), release somewhat less so (for a more rapid recovery). How deep into those will the firmware of the gateway allow you?
I believe the rtt setting in cake is another tuning parameter, similar to aligning overhead with the MTU your ISP uses, and similarly important to its correct/intended functioning:
when I changed mine to more closely reflect pings to their server (metro, 10ms because I reliably ping in the 7-8ms range), my ac86 calmed right down and sped right up - jitter went below 0.2ms, packet loss all but disappeared, upload stabilised at slightly above purchased speed (download still varies according to load/demand, which is as it should be, but can occasionally tick above purchased speeds in low/no load conditions).
(Now that I've seen a gateway that can be configured to tune the filter on the line, I suspect my connection can be made to give me more, if I can find how to access the tuning parameters...)
You can specify the roundtrip time in nanoseconds if you'd like to test a bit more finegrained control (although what this actually does, I can't say, squash packets into smaller lanes and hurry on to deal with the next faster? Throughput will suffer by emphasising this effort to lower latency.)
Instead of the metro option, try
Code:
rtt 8000
for 8ms.
I'll definitely get round to tweaking the SNR this weekend, I didn't realise it could do 0.1dB inc/decrements - very snazzy
You can specify the roundtrip time in nanoseconds if you'd like to test a bit more finegrained control (although what this actually does, I can't say, squash packets into smaller lanes and hurry on to deal with the next faster? Throughput will suffer by emphasising this effort to lower latency.)
Instead of the metro option, try
Code:
rtt 8000
for 8ms.
I'll definitely get round to tweaking the SNR this weekend, I didn't realise it could do 0.1dB inc/decrements - very snazzy
wowzers...that's super, the ability to input a more exact rtt/ping. Thank you!
I'm speculating -purely speculating- that this setting is for some sort of check, as in "at MTU XX, I can move xx packets per ping interval" and massages things in the background for stability
and 0.1dB increments is indeed snazzy...but what about a threshold parameter for the expander/gate? that's where the real meat and potatoes will be found in customizing the connection. the speed could really be pushed if you have a better idea of the range the signal voltage is over the noise floor of the connection - BUT you'd have to leave enough wiggle room for the noise floor to vary upwards as well as down
wowzers...that's super, the ability to input a more exact rtt/ping. Thank you!
I'm speculating -purely speculating- that this setting is for some sort of check, as in "at MTU XX, I can move xx packets per ping interval" and massages things in the background for stability
I wish I knew - Planning for the worst connection scenario we have, is the rtt for download between router and ISP's provided WAN IP? I find the wording in the manpages a bit confusing. Do we not want a more general rtt for you and the ips you connect to for internet usage? 100ms is very pessimistic if it's usually say... 20-40ms rtt to ping a given everyday website.
Similarly, is the upload rtt exactly the same number or is it between your LAN devices and the router? In which case that is going to be only a couple of ms? (3ms at worst on my end over wifi). The manpage does discourage going as low as 1ms since we can't customise the kernel very much either.
It's quite generous that it works well even 'within an order of magnitude' but there is a definite snappiness to tweaking this, shaving max throughput for lower latency.
Very short latencies require a very rapid AQM response to adequately
control latency. However, such a rapid response tends to impair
throughput when the actual RTT is relatively long. CAKE allows
specifying the RTT it assumes for tuning various parameters. Actual
RTTs within an order of magnitude of this will generally work well
for both throughput and latency management.
lan
For pure Ethernet (not Wi-Fi) networks, at home or in the
office. Don't use this when shaping for an Internet access link.
Equivalent to rtt 1ms.
and 0.1dB increments is indeed snazzy...but what about a threshold parameter for the expander/gate? that's where the real meat and potatoes will be found in customizing the connection. the speed could really be pushed if you have a better idea of the range the signal voltage is over the noise floor of the connection - BUT you'd have to leave enough wiggle room for the noise floor to vary upwards as well as down
At the 'lan' setting and below, the time constants are similar in
magnitude to the jitter in the Linux kernel itself, so congestion
might be signalled prematurely. The flows will then become sparse and
total throughput reduced, leaving little or no back-pressure for the
fairness logic to work against. Use the "metro" setting for local
lans unless you have a custom kernel.
I'm not using that gateway/modem, so I can only speculate what its GUI might have displayed for users to adjust. Can you screenshot that section/page and post it? something may jump out at me...or it may require a proper telco line scan tool for a readout of what the signal voltage is at and where the noise floor sits to dig in as deep as I suspect can be done.
There's theory and there's practical application, and the ISP people decide to err on the side of theoretical applications based in fact. practical artful application is where I make my living, but the principles are astonishingly similar once you understand the math and terminology.
And we should take this to its own thread or even to DMs as it is veering WAY off-piste from the header/title
In my super quick testing, reducing rtt below the time to the first hop (plus a little overhead) resulted in reduced throughput. It would seem based on this, that rtt functions something like an fine-tune setting.
if latency above rtt > throttle harder
I suspect that changing the value is only really useful in very specific cases to fully optimize and target a specific use (data center/high latency satellite), and won't have any real value for typical conditions.
Actual RTTs within an order of magnitude of this will generally work well for both throughput and latency management.
SNBForums is a community for anyone who wants to learn about or discuss the latest in wireless routers, network storage and the ins and outs of building and maintaining a small network.
If you'd like to post a question, simply register and have at it!
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.
