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!

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?
[1-7]: 4

Select Setting To Modify:
[1] --> Download Speed | [35 Mbit]
[2] --> Upload Speed | [36 Mbit]
[3] --> Queue Priority | [diffserv8]

[4] --> Extra Download Options | [overhead 39]

[5] --> Extra Upload Options | [overhead 39]

[e] --> Exit

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?
 
denmark still isn't particularly close to cambridge. while distance isn't a massive factor, testing closer servers usually produces better results
I'm in UK, and have been getting fairly consistent results using netperf-eu.bufferbloat.net

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.
What settings did you eventually settle upon?
 
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?
You and I have exactly the same setup except I've got the AC86U. :)

I've done some testing in the past few months and settled on:
Code:
[1]  --> Download Speed             | [0 Mbit]                                
[2]  --> Upload Speed               | [0 Mbit]                                
[3]  --> Queue Priority             | [diffserv4]                             
[4]  --> Extra Download Options     | [docsis nowash regional]                
[5]  --> Extra Upload Options       | [docsis ack-filter regional]

Have a play around and see what seems to work well when you're downloading big files or streaming/gaming since there are subtleties. :D 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 :p

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

CAKE 70-18 dual srchost + dual dsthost, besteffort, ptm overhead 26
............................................................
Download: 64.13 Mbps
Latency: (in msec, 60 pings, 0.00% packet loss)
Min: 16.548
10pct: 16.760
Median: 17.256
Avg: 17.335
90pct: 17.848
Max: 20.561
............................................................
Upload: 16.47 Mbps
Latency: (in msec, 60 pings, 0.00% packet loss)
Min: 16.358
10pct: 16.731
Median: 18.365
Avg: 18.312
90pct: 19.331
Max: 21.103

CAKE *0*-18 dual srchost + dual dsthost, besteffort, ptm overhead 26
Download: 67.89 Mbps
Latency: (in msec, 60 pings, 0.00% packet loss)
Min: 16.327
10pct: 16.610
Median: 17.261
Avg: 17.619
90pct: 19.320
Max: 21.941
............................................................
Upload: 16.46 Mbps
Latency: (in msec, 60 pings, 0.00% packet loss)
Min: 16.451
10pct: 16.797
Median: 18.389
Avg: 18.717
90pct: 20.102
Max: 31.338
 
You and I have exactly the same setup except I've got the AC86U. :)

I've done some testing in the past few months and settled on:
Code:
[1]  --> Download Speed             | [0 Mbit]                               
[2]  --> Upload Speed               | [0 Mbit]                               
[3]  --> Queue Priority             | [diffserv4]                            
[4]  --> Extra Download Options     | [docsis nowash regional]               
[5]  --> Extra Upload Options       | [docsis ack-filter regional]

Have a play around and see what seems to work well when you're downloading big files or streaming/gaming since there are subtleties. :D 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 :p

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

CAKE 70-18 dual srchost + dual dsthost, besteffort, ptm overhead 26
............................................................
Download: 64.13 Mbps
Latency: (in msec, 60 pings, 0.00% packet loss)
Min: 16.548
10pct: 16.760
Median: 17.256
Avg: 17.335
90pct: 17.848
Max: 20.561
............................................................
Upload: 16.47 Mbps
Latency: (in msec, 60 pings, 0.00% packet loss)
Min: 16.358
10pct: 16.731
Median: 18.365
Avg: 18.312
90pct: 19.331
Max: 21.103

CAKE *0*-18 dual srchost + dual dsthost, besteffort, ptm overhead 26
Download: 67.89 Mbps
Latency: (in msec, 60 pings, 0.00% packet loss)
Min: 16.327
10pct: 16.610
Median: 17.261
Avg: 17.619
90pct: 19.320
Max: 21.941
............................................................
Upload: 16.46 Mbps
Latency: (in msec, 60 pings, 0.00% packet loss)
Min: 16.451
10pct: 16.797
Median: 18.389
Avg: 18.717
90pct: 20.102
Max: 31.338
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 :D , 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 :D , 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?
Thanks for the response.
The speed tests are all performed directly on the router (ASUS AX88U which is connected to the Draytek Vigor 130).
 
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?
[1-7]: 4

Select Setting To Modify:
[1] --> Download Speed | [35 Mbit]
[2] --> Upload Speed | [36 Mbit]
[3] --> Queue Priority | [diffserv8]

[4] --> Extra Download Options | [overhead 39]

[5] --> Extra Upload Options | [overhead 39]

[e] --> Exit

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?
Any one ?
 
Any one ?


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"!!!


[1] --> Download Speed | [65 Mbit]
[2] --> Upload Speed | [3 Mbit]
[3] --> Queue Priority | [besteffort]
[4] --> Extra Download Options | [docsis ack-filter]
[5] --> Extra Upload Options | [docsis ack-filter]

Try this when messing with the different speeds setup:

 
Last edited:
Any one ?
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 :D , 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?
Yes. The Draytek Vigor 130 modem allows setting values in 0.1 db precision.
 
Yes. The Draytek Vigor 130 modem allows setting values in 0.1 db precision.
My inclination would be to tread lightly going below 5.0dB with those 0.1dB steps...
 
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 :cool:
 
Last edited by a moderator:
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 :cool:
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

I fear that sounds a bit beyond my skillset atm lol Is this possible entirely through software?
 
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.

It recommends going no lower than metro (10ms) for lan, so I might leave it at that for upload for a bit and see how it goes :p

Code:
[1]  --> Download Speed             | [0 Mbit]                               
[2]  --> Upload Speed               | [0 Mbit]                               
[3]  --> Queue Priority             | [diffserv4]                             
[4]  --> Extra Download Options     | [docsis nowash rtt 40000]               
[5]  --> Extra Upload Options       | [docsis ack-filter metro]
 
I fear that sounds a bit beyond my skillset atm lol Is this possible entirely through software?
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.

You can also specify measurement method. Rather than "8000", you can use "8 ms".
 

Similar threads

Latest threads

Sign Up For SNBForums Daily Digest

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