Okay, go ahead and take your Per Packet Overhead from 18 to 22 (where it should be for cable).
I would like to see what happens if we try to get you onto cake/piece_of_cake instead of fq_codel/simple. If you're willing to switch these settings and test again, it will be interesting to see if your router can handle this:
Ouch, yeah that cake test was rough, like I figured it would be. While still on the cake configuration, copy and paste all of this into your SSH session for me and then run the speed test again:
So at this point, we have your CPU governor set in performance mode and it's statically set at your CPU's top speed (1.725Ghz). Cake is CPU intensive, as I have mentioned before, so I was trying to throw all the CPU we possibly can into the mix.
Do you, by any chance, have a decently powerful desktop/notebook that is connected via Ethernet back to your router? If so, could you run a speed test (dslreports.com/speedtest, ideally) from there with all the settings as they are? Don't try the test over wireless as this point.
Would you be able to connect it to the router via ethernet and switch the wireless off for a test? If not, that's fine. The goal in having you test this way, if possible, is because the speedtest-netperf.sh script creates a certain amount of CPU overhead in and of itself just to run. I wanted to remove that overhead from your router's CPU and let your router concentrate on only routing/shaping to see if that max download speed improves a bit while still on cake.
Alright, so it's pretty clear that your R7800 isn't going to be able to keep up with your ingress speed on cake qdisc. You still got decent improvements with fq_codel/simple for your Queue Discipline settings in SQM. You'll probably want to switch back over to those settings, but keep the Ethernet link layer and 22bytes per packet overhead as they are.
I would be interested to see if dslreports.com gives you the same A+ buffer bloat rating when you switch back to fq_codel/simple.
So the next step would be to continue tweaking your download/upload speeds once back on fq_codel/simple until you find the sweet spot between throughput vs. latency.
Since you're a gamer, you might have to make a bit of a decision between trying to squeeze out as much throughput as you can to "get your money's worth" out of what you're paying, or be willing to sacrifice some throughput to gain a consistently low-latency connection.
Cool. So your last fq_codel/simple test with 22byte per packet overhead had you at 450mbps with just under 10ms 90pct and some CPU room to spare. I am pretty confident we can get you closer to 500-525mbps without adding too much more latency than that.
So here's what I typically would do... teaching moment...
Your latency is pretty great at 450mbps down. At 690mbps down, it was rough. So what I do when I'm tuning SQM (and others may do it differently) is take a known good number and a known bad number and split the difference.
Bad: 690mbps (706560kbps)
Good: 488mbps (500000kbps) <-- where you are right now
Diff: 201.7mbps (206560kbps) / 2 = 100.9mbps (103280kbps)
So add the Diff kbps to the Good kbps and you have your next testing figure:
500000kbps + 103280kbps = 603280kbps
Plug 603280 (you could round down to 600000 at this point if you'd like) in for your download speed and test again.
At that point you have a binary decision--were the avg and 90pct latency significantly worse?
If yes, then your Diff number was too high still. So I take the difference of the last known good (500000 in your case) and the number you just tested at (600000 in this example), divide the difference by 2, add that back to the last known good number and try again (so 550000 in this case).
If no, then your new good number becomes 600000. So then you take the difference between 600000 and your last known bad number (706560 in your case), divide the difference by 2, add the difference back to the new good number, and test again.
You basically keep going with that binary testing method until you reach a point where you start to see consistently higher latency test over test, then you back it back down until you see that latency continue to stay reasonably low in the avg and 90pct.
That will get you pretty close to tuned up--at least enough so that you are going to start seeing advantages in your browsing and gaming responsiveness. When you get your download where you think it's good, you'll repeat the same process on the upload. I would exercise more discretion on watching for latency increases on the upload because of your gaming needs. You want your upload latency to be as consistently low as possible. I would go more by the 90pct figure on upload as opposed to avg.
That said, what works great one day might not be so great the next day due to factors outside your control (general internet congestion, congestion on your shared cable medium, alignment of the moon and stars, etc.). The goal overall is not to get it perfect in one night, but to get it running as consistently "good" (no major lag spikes, pretty consistent latency at all times of the day) as possible over, say, a week or two. Think of this as more of a marathon and not a sprint.
Everything works great on ps4 when other devices aren’t being used. Such as fire sticks, TVs with WiFi, iPhones.. is there a way to prioritize bandwidth to each devices like qos
It requires CPU as well, so you have to make sure you have some left to handle the additional load. Having said that, I have the same router, a PS4, and may wireless client and never had any issues.
In my setup I only move 5GHz to CPU1 while everything else stays on CPU0
Software offload enabled
All *ps_cpus are set to 3 scaling_min_freq are set to 800000 (and a few more ondemand tweaks, but they are less important)
R7800 cannot shape in both directions, so I only shape the upload at 200Mbps max; anything more than that creates issues
