Can someone at VM confirm this is congestion, or whether it's a fault? Modem mode (fairly new Sh3), direct connection with confirmed good Cat5e cabling, tested and confirmed on Linux, BSD, macOS and Windows 10 - just to be sure lol. I also checked the connections are tight on the back of the hub (and yes, it's been hard power cycled).
I've used iperf3 (to a 10Gbps server) as well as speedtest.net and dslreports' speedtest, all of which agree our speeds have gone to pot. I'm seeing speeds as low as 70Mbps during peak times, mostly hovering around 150Mbps (still below fault threshold). Modem power levels are within spec (though higher than they used to be).
1 10.42.240.1 (10.42.240.1) 16.754 ms 17.054 ms 17.282 ms
2 pres-core-2b-xe-521-0.network.virginmedia.net (184.108.40.206) 17.648 ms 17.876 ms 18.036 ms
so I assume those are the ones you want pinging? The first one doesn't respond to ping (but did give the above on a traceroute). The second one, which I assume is the CMTS(?) is:
> ping -c 20 220.127.116.11 ~
PING 18.104.22.168 (22.214.171.124) 56(84) bytes of data.
64 bytes from 126.96.36.199: icmp_seq=1 ttl=63 time=16.5 ms
64 bytes from 188.8.131.52: icmp_seq=2 ttl=63 time=14.9 ms
64 bytes from 184.108.40.206: icmp_seq=3 ttl=63 time=11.10 ms
64 bytes from 220.127.116.11: icmp_seq=4 ttl=63 time=16.0 ms
64 bytes from 18.104.22.168: icmp_seq=5 ttl=63 time=12.4 ms
64 bytes from 22.214.171.124: icmp_seq=6 ttl=63 time=11.10 ms
64 bytes from 126.96.36.199: icmp_seq=7 ttl=63 time=10.9 ms
64 bytes from 188.8.131.52: icmp_seq=8 ttl=63 time=18.7 ms
64 bytes from 184.108.40.206: icmp_seq=9 ttl=63 time=10.8 ms
64 bytes from 220.127.116.11: icmp_seq=10 ttl=63 time=14.4 ms
64 bytes from 18.104.22.168: icmp_seq=11 ttl=63 time=13.1 ms
64 bytes from 22.214.171.124: icmp_seq=12 ttl=63 time=10.1 ms
64 bytes from 126.96.36.199: icmp_seq=13 ttl=63 time=8.55 ms
64 bytes from 188.8.131.52: icmp_seq=14 ttl=63 time=13.1 ms
64 bytes from 184.108.40.206: icmp_seq=15 ttl=63 time=13.2 ms
64 bytes from 220.127.116.11: icmp_seq=16 ttl=63 time=10.1 ms
64 bytes from 18.104.22.168: icmp_seq=17 ttl=63 time=8.25 ms
64 bytes from 22.214.171.124: icmp_seq=18 ttl=63 time=11.1 ms
64 bytes from 126.96.36.199: icmp_seq=19 ttl=63 time=11.5 ms
64 bytes from 188.8.131.52: icmp_seq=20 ttl=63 time=11.1 ms
--- 184.108.40.206 ping statistics ---
20 packets transmitted, 20 received, 0% packet loss, time 46ms
rtt min/avg/max/mdev = 8.250/12.429/18.725/2.588 ms
The BQM doesn't normally spike in the evenings, but does get scattered packet loss at random times of day. My speeds only ever dip from about 6pm until just after midnight. Coincidentally they go back to >540Mbps then... congested area or not.
Odd one this, as everything looks fine, a small blip of packet loss on the BQM, and it is not unusual to get a few ping spikes during peak times, it may be a sign of the circuit is busy or you are heavily using the internet at the time, but it doesn't look like contention although what you describe does sound like contention. It may be worth asking any neighbours with a VM connection if they are experiencing the same issue.
Are you testing with only one device connected to the internet at the time?
Your stats look fine, upstream and downstream power is in spec, downstream SNR is fine with a low RS error count. The range of power levels could be a symptom of your connection being a distance away from the street cab as higher frequencies attenuate faster than the lower frequencies. The power slope does look a tad steep but i would imagine is still be within Docsis specs, VM will need to confirm though.
I wouldn't worry about the odd T3 in the logs and the one RCS error in three weeks does not mean you are not currently locking on to a full set of downstream channels, it looks like you may have very briefly lost one or two channels, but nothing to explain prolonged slow speeds. You shouldn't really lose much speed with the Hub is in Partial Service mode if your local circuit is not too busy as the data the lost channel would have carried would be carried by the working channels. (apart from the time the CMTS takes to realise the Hub is in Partial Service mode).
As I said, odd one this, there is nothing in your stats to explain the slow speeds and it looks like you have comprehensively tested the speeds, including the normal test of testing with the Hub in modem mode with a PC in safe mode with networking (Windows). As the issue is time sensitive it is unlikely to be hardware related, but always worth trying another ethernet cable, testing with a wireless AC device etc.
It could be an upstream contention issue which VM could arrange to check when they visit the thread.