Well different DN-server can direct you to different nodes in cloudflare's network and these can be loaded differently. This might indicate that throughput and latency for the wavefront test might not be limited by your own router...
It would be interesting to see:
output of tc -s qdisc (copy and paste the output as 'Preformatted Text')
run a speedtest and post the results here (copy and paste the result link)
immediately after the speedtest finishes run tc -a qdisc again (copy and paste the output as 'Preformatted Text')
Possible, but still inconclusive as it is not clear whether wavefront/cloudflare works well for you, you can realistically only address the bufferbloat on your access link, but the wavefront tests will report the aggregate bufferbloat including bloat on segments of the path outside of your home network.
Wavefront uses cloudfront for its data sinks and sources. My theory is that switching from your (ISP's?) default DN-servers to Google's DN-servers might simply steer you towards different cloudflare nodes. Sorry, I probably should have elaborated on this.
These specific compilation switches could improve size, power, or performance. It would be nice if you could share the script to build with those optimizations or compare it against the standard build without them. If the optimization is effective and it is not generating any side effects, it could, and should, be included in the master.
I've given up on pushing any kind of optimization that increases size due to previous efforts simply because it's not worth the effort. I think they're still people trying to get builds using NEON optimizations accepted at least one year later. There have also been attempts trying to make x86-64 more modern with little success.
That will all depend on the number of users using a given optimization. in the R7800 I seethe NSS drivers coming soon as default due to the speed increase. The best you can do to make any optimization going into master is to promote it.
Size is not a problem in these routers. I am sure if you share here your experiments (scripts, results, etc) they will be replicated by many people. A repo can be forked in seconds and others could leverage your results to go even further.
Depending on your overhead configuration the best you can expect to measure as IPv4/TCP throughput (the stuff that on-line speedtests measure, also called goodput):
both netflix's fast.com and Ookla's speedtest.net results look within the expected. For Okkla the challenge is that individual measurement servers only need to be connected vie 1 Gbps ethernet, and if you measure against such a node and other speedtests are also running at the same time it might be hard to saturate ...
Thanks. (after seeing your reply I set it to the followong) but... I'm using: 900000 & 50000 but the latency from the waveshare website is going over 100+ - honestly, not sure what else to try.
My DNS is set to 8.8.4.4 & 8.8.8.8, it's set to fq_codel & simplest_tbf
I don't have packet sheering on nor do I have irqbalence installed.
Am I missing something?
Is my Internet pure crap?????
Thanks. It would be more convenient to directly paste the text here into the forum. Just sandwich it between lines consisting out of three backticks each:
```
line 1 text
line 2 text
more text
```
resulting in:
line 1 text
line 2 text
more text
I think we already established that the wavefront test seems unreliably for you, so this is not unexpected. The question here still is, does that bufferbloat reflect what is going on on your link or is that happening upstream of you.
Did you click on the "use http" link a recommended in note 5:
"1. Some/most/all? SSL certificates of the dslreports speedtest servers seem to cause issues with modern browsers, so make sure to run the test over http instead of https. There is a clickable link (use http) on the top right corner of the widget in which to select the test type, make sure to click this."
Also, you could try it with a different browser...
I understand your frustration to a degree, but it seems more productive to withhold judgements until their certainty is high...