Increased ping times - what is normal / acceptable?

[Bilbomacuser]

We are on the 350 plan (which when we signed up was the fastest service, for gamers) and we have typically had a ping of around 8-12 ms.  Recently I’ve noticed it to be 18-20ms.   We are still getting good speeds - of around 360 mbps up and 36 mbps down.  The hub 3 is in modem only mode.

The cover of the brown box outside regularly falls of and I keep replacing it - should the box be replaced, and could this be causing issues?

There are some errors showing on the status page:

17/07/2021 23:34:28	notice	LAN login Success;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
16/07/2021 20:50:48	critical	No Ranging Response received - T3 time-out;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
16/07/2021 20:50:24	critical	Unicast Maintenance Ranging attempted - No response - Retries exhausted;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
16/07/2021 20:50:24	critical	Ranging Request Retries exhausted;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
16/07/2021 19:23:29	critical	No Ranging Response received - T3 time-out;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
13/07/2021 19:13:5	Error	DHCP RENEW WARNING - Field invalid in response v4 option;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
11/07/2021 14:21:42	critical	No Ranging Response received - T3 time-out;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
10/07/2021 05:41:53	Error	DHCP RENEW WARNING - Field invalid in response v4 option;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
08/07/2021 14:30:57	critical	No Ranging Response received - T3 time-out;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
08/07/2021 09:20:59	Warning!	RCS Partial Service;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
08/07/2021 09:20:57	critical	SYNC Timing Synchronization failure - Loss of Sync;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
08/07/2021 09:20:57	Warning!	RCS Partial Service;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
08/07/2021 08:42:29	critical	Received Response to Broadcast Maintenance Request, But no Unicast Maintenance opportunities received - T4 time out;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
08/07/2021 08:38:8	Warning!	Lost MDD Timeout;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
08/07/2021 08:38:3	critical	SYNC Timing Synchronization failure - Loss of Sync;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
08/07/2021 08:38:3	Warning!	RCS Partial Service;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
08/07/2021 08:38:2	critical	SYNC Timing Synchronization failure - Loss of Sync;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
05/07/2021 19:51:50	critical	No Ranging Response received - T3 time-out;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
05/07/2021 02:39:2	Error	DHCP RENEW WARNING - Field invalid in response v4 option;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
02/07/2021 20:53:26	critical	No Ranging Response received - T3 time-out;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;

Channel Channel Type T1 Timeouts T2 Timeouts T3 Timeouts T4 Timeouts

1	ATDMA	0	0	46	0
2	ATDMA	0	0	0	0
3	ATDMA	0	0	0	0
4	ATDMA	0	0	0	0

Downstream bonded channelsChannel Locked Status RxMER (dB) Pre RS Errors Post RS Errors

1	Locked	38.6	9	0
2	Locked	37.6	31	0
3	Locked	37.6	16	0
4	Locked	37.6	24	0
5	Locked	37.6	53	0
6	Locked	37.6	56	0
7	Locked	37.3	27	0
8	Locked	37.3	25	0
9	Locked	37.6	18	0
10	Locked	37.3	24	0
11	Locked	37.6	27	0
12	Locked	37.6	16	0
13	Locked	37.6	35	0
14	Locked	37.3	7	0
15	Locked	37.6	34	0
16	Locked	37.6	30	0
17	Locked	37.6	23	0
18	Locked	37.3	30	0
19	Locked	37.3	47	0
20	Locked	37.3	31	0
21	Locked	37.3	35	0
22	Locked	36.6	56	0
23	Locked	36.6	98	0
24	Locked	36.3	272	0

[Andrew-G · Accepted solution]

Looking at what you've posted, it seems likely that the problem is caused by noise ingress on upstream channel 1.  If you look there's a very high timeout count on that, which will affect the hub's communication with the network.  I've marked that for staff to advise.  If need be they can book a technician.

[jb66]

46 is not alot if the hubs been online for a while.

It's normal to have latency of 20ms+ on Virgin as docsis3 is laggier than say Openreach FTTC. That's not a fault/issue

Perhaps post up your full stats showing your upstream power levels etc 

[Bilbomacuser]

Thanks for the replies. 

The hub was restarted about 24 hours earlier when I installed a new router (changed from Synology RT2600ac to UDM Pro) - the Virgin Hub 3 has been powered off during the switchover as I had read this was necessary to work with a new router. 

We have had consistently lower ping times with Virgin previously (about 8-12ms) so it is now about twice what it was previously. The cabinet is opposite our house so perhaps that allows low ping times normally?

Any stats I’ve missed?

Downstream bonded channelsChannel Frequency (Hz) Power (dBmV) SNR (dB) Modulation Channel ID

1	203000000	5.4	38	256 qam	9
2	211000000	4.5	37	256 qam	10
3	219000000	4.6	37	256 qam	11
4	227000000	4	37	256 qam	12
5	235000000	3	37	256 qam	13
6	243000000	2.7	37	256 qam	14
7	251000000	3.5	37	256 qam	15
8	259000000	4	37	256 qam	16
9	267000000	4.3	37	256 qam	17
10	275000000	4.5	37	256 qam	18
11	283000000	4.5	37	256 qam	19
12	291000000	4.9	38	256 qam	20
13	299000000	4.9	37	256 qam	21
14	307000000	5.4	37	256 qam	22
15	315000000	5.1	37	256 qam	23
16	323000000	5.5	37	256 qam	24
17	331000000	5.3	37	256 qam	25
18	339000000	6	37	256 qam	26
19	347000000	5.6	37	256 qam	27
20	355000000	6	37	256 qam	28
21	363000000	4.8	36	256 qam	29
22	371000000	3.9	36	256 qam	30
23	379000000	3.7	36	256 qam	31
24	387000000	3.5	36	256 qam	32

 
Upstream bonded channelsChannel Frequency (Hz) Power (dBmV) Symbol Rate (ksps) Modulation Channel ID

1	53700000	44.8	5120	64 qam	2
2	60300000	44.8	5120	64 qam	1
3	46200000	44.5	5120	64 qam	3
4	39400000	44	5120	64 qam	4

   
Upstream bonded channelsChannel Channel Type T1 Timeouts T2 Timeouts T3 Timeouts T4 Timeouts

1	ATDMA	0	0	46	0
2	ATDMA	0	0	0	0
3	ATDMA	0	0	0	0
4	ATDMA	0	0	0	0

General Configuration

Network access	Allowed
Maximum Number of CPEs	1
Baseline Privacy	Enabled
DOCSIS Mode	Docsis30
Config file	cmreg-vmdg505-bbt062-b.cm

Primary Downstream Service Flow

SFID	38284
Max Traffic Rate	402500089
Max Traffic Burst	42600
Min Traffic Rate	0

Primary Upstream Service Flow

SFID	38283
Max Traffic Rate	38500089
Max Traffic Burst	42600
Min Traffic Rate	0
Max Concatenated Burst	42600
Scheduling Type	BestEffort

[Ayisha_B]

Hi @Bilbomacuser,

Welcome to our Community Forums and thanks for posting. 

I have taken a look at the account but have been unable to run through all the diagnostics as you are currently in Modem mode. Are you able to put the hub into router mode so I can finish of our checks?

Cheers

[Andrew-G]

@jb66   46 is not alot if the hubs been online for a while.

Look at the downstream error counts - if the hub had any extended up time those would be far higher.

[Bilbomacuser]

Thanks for the reply.  I will put it in router mode now - will I need to leave it like that for long?

Thanks

Jon

[Andrew-G]

---

@Bilbomacuser wrote:

Thanks for the reply.  I will put it in router mode now - will I need to leave it like that for long?

---

A couple of days usually.  If that causes wifi problems you can reconnect your own router but with YOUR router set to access point mode, and turn off the hub's wifi.  That means you get better wifi but still enables VM to remotely interrogate the hub.  You don't want that long term, because the hub's router is not up to much, but as a short term thing it is usually an acceptable compromise.

[Eeeps]

---

@Andrew-G wrote:

---

@Bilbomacuser wrote:

Thanks for the reply.  I will put it in router mode now - will I need to leave it like that for long?

---

A couple of days usually.  If that causes wifi problems you can reconnect your own router but with YOUR router set to access point mode, and turn off the hub's wifi.  That means you get better wifi but still enables VM to remotely interrogate the hub.  You don't want that long term, because the hub's router is not up to much, but as a short term thing it is usually an acceptable compromise.

---

The other option that may work for you is to leave both as gateway routers and double NAT. This is less disruptive in terms of configuration of your internal devices.
For this to work, there will be a small local subnet between the SH and your router. You must chose an IP range for this that does not conflict with your main local subnet.

1. Place the SH in router mode. Set a static ip for the SH and Disable DHCP on the SH
2. Set a static ip on the WAN interface on your router in the SHs range
3. On the SH put your router in the DMZ. This will forward all external ports to your router.
4. Disable WiFi on the SH

I've run like this for more than a week with no noticeable changes in functionality from a local network standpoint. (I run outgoing and incoming VPNs)

It's also very easy to put back into modem mode. Connect to the SH (via your router) on the static IP you gave it. Switch the SH to modem mode.
Then put your routers WAN back to DHCP and power cycle the SH.

[Ayisha_B]

Thanks for popping the hub back into router mode @Bilbomacuser

I have taken a look at your account and can see you are currently impacted by an outage. 

The reference number for this is C01217103 and the estimated time of fix is 19 JUL 2021 15:00

We need to let you know we're making some improvements to our network at the moment, so we can make sure we're giving you the best service possible.

I would advise rebooting your hub and monitoring your connection thereafter and if you find the issues still persist, let us know and we can take it from there. 

Cheers