Apologies for the updates: filling in the the answers here. Unfortunately, my USB-C → Ethernet adapter is not being cooperative, but have ordered another, so I'll fill in the responsiveness test soon as well.
Those are good latency numbers for coax. You'll always have about 10ms-15ms extra over a pure ethernet solution like FIOS or true Ethernet, but those increases are pretty much negligible. And yes, looks like no buffer bloat at all.
You can test the Google Drive upload with and without cake, btw, and see if that slow rampup was due to the codel algo or something inherent to Google's or Slectrum's networks. Im not familiar with cake, but I remember that fq-codel could be tweaked to deal better with fast connections. The defaults that I've seen were better suited to 100-200Mb speeds.
Edit: just saw the latest speed updates you posted. Thank you. Those still look pretty good, considering that this is residential cable we're talking about. Even 443Mbps is still gamechanging compared to the standard 35Mbps most cable services provide.
Edit2: and the latencies look fantastic for all of those tests, even the ones with the slowest uploads (congestion?). Spectrum could be up against limits at their edge, with their peering connections.
Ah, great point. CAKE does have some parameters, but haven't had a chance to look again. Here's what I have (the Evenroute defaults way back when) in OpenWRT at the moment:
qdisc (ingress):
Code:
nat dual-dsthost ingress docsis mpu 64
qdisc (egress):
Code:
nat ack-filter-aggressive dual-srchost mpu 64
I ran the re-ran file upload test with CAKE enabled and disabled (the whole package was disabled when disabled). This is with a 4.19GB video file (size reported by Google Drive after upload), just manually timed with a stopwatch. There is a maybe a few seconds added per file as Google has a "finalizing upload", but it was less than 10s each run. Just one run each, which is not very scientific, however.
| 4.19GB video file | Time to Complete | Estimated Upload Capacity |
| CAKE fully enabled | 2 minutes, 18 seconds | 243 Mbps |
| CAKE fully disabled | 2 minutes, 59 seconds | 187 Mbps |
There is a fair amount of ratchecting / sawtooth throughout the upload, CAKE on or off, but this is also on a "live" network. Nothing else showed up in Task Manager consuming more than 3 Mbps, however.
Cake fully disabled
Cake fully enabled:
Installed Speedest's CLI, so now we can see bufferbloat
and the total upload capacity at once. Upload latency has increased, of note, but not egregiously (sans the 305ms max).
Use Speedtest on all your devices with our free desktop and mobile apps.
www.speedtest.net
Code:
Speedtest by Ookla
Server: Spectrum - Columbus, OH (id: 63372)
ISP: Spectrum
Idle Latency: 15.30 ms (jitter: 0.68ms, low: 14.42ms, high: 15.92ms)
Download: 918.87 Mbps (data used: 982.5 MB)
20.29 ms (jitter: 3.07ms, low: 13.68ms, high: 39.60ms)
Upload: 935.25 Mbps (data used: 1.1 GB)
42.10 ms (jitter: 6.60ms, low: 13.61ms, high: 305.36ms)
Packet Loss: 0.0%
//
One dumb test i would want to know. What happens if you load like 50 torrent files with 1000 connections. And then seeing if the router/modem they provide how it deals with it. Like does the speed test's ping/jitter go downhill fast?
Ah, that might be interesting, too. I've not used torrents in many years now: 50 torrents seems doable, but 1000 connections is where I'm lost. Is there an easy way to verify how many connections get made and / or ensure I get ~1000?
