Menu
Reply
Highlighted
  • 84
  • 1
  • 26
RainmakerRaw
Up to speed
215 Views
Message 1 of 8
Flag for a moderator

500Mbps dropping as low as <100Mbps

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). 

8501825074.png

TBB graph for today is here.

0 Kudos
Reply
  • 11.5K
  • 765
  • 3.34K
Superuser
Superuser
208 Views
Message 2 of 8
Flag for a moderator

Re: 500Mbps dropping as low as <100Mbps

500 , we are told, will not be sold in congested areas so, no. Smiley Tongue

I know you know what your at, but post power-levels and network logs anyway...

BQM looks like latency is higher than average- can you post a ping to the gateway and then the local CMTS? Say 20 instances?

 

 


0 Kudos
Reply
  • 84
  • 1
  • 26
RainmakerRaw
Up to speed
196 Views
Message 3 of 8
Flag for a moderator

Re: 500Mbps dropping as low as <100Mbps

The first two hops from the router are:

 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 (80.0.160.169)  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 80.0.160.169                                                      ~
PING 80.0.160.169 (80.0.160.169) 56(84) bytes of data.
64 bytes from 80.0.160.169: icmp_seq=1 ttl=63 time=16.5 ms
64 bytes from 80.0.160.169: icmp_seq=2 ttl=63 time=14.9 ms
64 bytes from 80.0.160.169: icmp_seq=3 ttl=63 time=11.10 ms
64 bytes from 80.0.160.169: icmp_seq=4 ttl=63 time=16.0 ms
64 bytes from 80.0.160.169: icmp_seq=5 ttl=63 time=12.4 ms
64 bytes from 80.0.160.169: icmp_seq=6 ttl=63 time=11.10 ms
64 bytes from 80.0.160.169: icmp_seq=7 ttl=63 time=10.9 ms
64 bytes from 80.0.160.169: icmp_seq=8 ttl=63 time=18.7 ms
64 bytes from 80.0.160.169: icmp_seq=9 ttl=63 time=10.8 ms
64 bytes from 80.0.160.169: icmp_seq=10 ttl=63 time=14.4 ms
64 bytes from 80.0.160.169: icmp_seq=11 ttl=63 time=13.1 ms
64 bytes from 80.0.160.169: icmp_seq=12 ttl=63 time=10.1 ms
64 bytes from 80.0.160.169: icmp_seq=13 ttl=63 time=8.55 ms
64 bytes from 80.0.160.169: icmp_seq=14 ttl=63 time=13.1 ms
64 bytes from 80.0.160.169: icmp_seq=15 ttl=63 time=13.2 ms
64 bytes from 80.0.160.169: icmp_seq=16 ttl=63 time=10.1 ms
64 bytes from 80.0.160.169: icmp_seq=17 ttl=63 time=8.25 ms
64 bytes from 80.0.160.169: icmp_seq=18 ttl=63 time=11.1 ms
64 bytes from 80.0.160.169: icmp_seq=19 ttl=63 time=11.5 ms
64 bytes from 80.0.160.169: icmp_seq=20 ttl=63 time=11.1 ms

--- 80.0.160.169 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. Smiley Wink 

Modem downstream stats:

Spoiler
Channel Frequency (Hz) Power (dBmV) SNR (dB) Modulation Channel ID
1299000000237256 qam21
21390000006.538256 qam1
31470000006.338256 qam2
41550000005.838256 qam3
51630000005.438256 qam4
61710000005.438256 qam5
71790000004.838256 qam6
81870000004.538256 qam7
91950000003.738256 qam8
102030000003.238256 qam9
112110000003.238256 qam10
122190000002.737256 qam11
13227000000338256 qam12
142350000002.738256 qam13
152430000002.537256 qam14
162510000002.437256 qam15
172590000002.737256 qam16
182670000002.738256 qam17
192750000002.438256 qam18
202830000002.238256 qam19
212910000002.238256 qam20
223070000001.538256 qam22
233150000001.438256 qam23
24323000000137256 qam24


Downstream bonded channelsChannel Locked Status RxMER (dB) Pre RS Errors Post RS Errors
1Locked37.61200
2Locked38.6750
3Locked38.910615
4Locked38.91090
5Locked38.9890
6Locked38.6900
7Locked38.6900
8Locked38.61000
9Locked38.9880
10Locked38.6810
11Locked38.61040
12Locked37.61201
13Locked38.6970
14Locked38.6850
15Locked37.61140
16Locked37.6970
17Locked37.6930
18Locked38.61030
19Locked38.6870
20Locked38.91150
21Locked38.61100
22Locked38.61090
23Locked38.61370
24Locked37.61610

Modem upstream stats:

 

Spoiler
Upstream bonded channelsChannel Frequency (Hz) Power (dBmV) Symbol Rate (ksps) Modulation Channel ID
1394000074.45512064 qam12
2462000244.45512064 qam11
3537000364.6512064 qam10
4603000514.7512064 qam9


Upstream bonded channelsChannel Channel Type T1 Timeouts T2 Timeouts T3 Timeouts T4 Timeouts
1ATDMA0000
2ATDMA0000
3ATDMA0000
4ATDMA0000
0 Kudos
Reply
  • 84
  • 1
  • 26
RainmakerRaw
Up to speed
193 Views
Message 4 of 8
Flag for a moderator

Re: 500Mbps dropping as low as <100Mbps

Modem logs:

Spoiler
Network LogTime Priority Description
24/07/2019 18:18:33noticeDHCP Renew - lease parameters tftp file-Vcb573b2ee9a9587e.cm modified;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
24/07/2019 21:39:41criticalNo Ranging Response received - T3 time-out;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
28/07/2019 13:47:25ErrorDHCP RENEW sent - No response for IPv4;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
29/07/2019 00:48:55criticalNo Ranging Response received - T3 time-out;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
29/07/2019 02:15:55ErrorDHCP RENEW sent - No response for IPv4;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
29/07/2019 14:44:28ErrorDHCP REBIND WARNING - Field invalid in response;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
29/07/2019 14:44:28noticeDHCP Renew - lease parameters tftp file-Vcb573b2ee9a9587e.cm modified;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
29/07/2019 22:37:31criticalNo Ranging Response received - T3 time-out;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
02/08/2019 11:56:38ErrorDHCP RENEW sent - No response for IPv4;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
03/08/2019 13:21:50ErrorDHCP REBIND WARNING - Field invalid in response;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
03/08/2019 13:21:50noticeDHCP Renew - lease parameters tftp file-Vcb573b2ee9a9587e.cm modified;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
04/08/2019 10:25:58criticalNo Ranging Response received - T3 time-out;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
04/08/2019 14:38:35Warning!RCS Partial Service;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
05/08/2019 06:15:45criticalNo Ranging Response received - T3 time-out;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
11/08/2019 12:03:8ErrorDHCP RENEW sent - No response for IPv4;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
12/08/2019 08:46:29criticalNo Ranging Response received - T3 time-out;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
12/08/2019 11:40:38ErrorDHCP RENEW sent - No response for IPv4;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
12/08/2019 19:33:10ErrorDHCP REBIND WARNING - Field invalid in response;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
12/08/2019 19:33:10noticeDHCP Renew - lease parameters tftp file-Vcb573b2ee9a9587e.cm modified;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
13/08/2019 07:42:38criticalNo Ranging Response received - T3 time-out;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
0 Kudos
Reply
  • 11.5K
  • 765
  • 3.34K
Superuser
Superuser
184 Views
Message 5 of 8
Flag for a moderator

Re: 500Mbps dropping as low as <100Mbps

That makes sense now

You are losing channels from the set the HUB is locked to. Put simply there is too much range in the power levels on the downstream, channel(s) drop=loss of speed

Im hitting my CMTS in 9 MS, your latency is higher, but given the issues with channels, doesn't look like congestion to me. Neither does your BQM trace

@ModTeam 

Can someone get a look and see if an engineer is required? My guess is yes, but there could be an area fault....

 


  • 11.58K
  • 1.06K
  • 2.5K
griffin
Alessandro Volta
159 Views
Message 6 of 8
Flag for a moderator

Re: 500Mbps dropping as low as <100Mbps

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.

  • 84
  • 1
  • 26
RainmakerRaw
Up to speed
155 Views
Message 7 of 8
Flag for a moderator

Re: 500Mbps dropping as low as <100Mbps

...and now we're comfortably past midnight.

[SUM]   0.00-10.00  sec   658 MBytes   552 Mbits/sec  527             sender
[SUM]   0.00-10.00  sec   655 MBytes   550 Mbits/sec                  receiver

iperf Done.

Screenshot 2019-08-15 at 00.53.47.png

53110940.png
DSLReports speedtest info and details

It certainly smells like congestion, but I'm happy for someone at VM to tell me otherwise and fix it.

0 Kudos
Reply
  • 1.97K
  • 57
  • 82
Forum Team
Forum Team
71 Views
Message 8 of 8
Flag for a moderator

Re: 500Mbps dropping as low as <100Mbps

Hi RainmakerRaw,

 

Thank you for your post. I'm sorry to hear about this. 

 

I will private message you now to look into this. 

 

^Martin

0 Kudos
Reply