High Frequency Latency Spikes

[CabbagesVM]

I started my service with VM around October 2021. My broadband up to now has been, for the most part, flawless and remedied the main reason that I ended my contract early with Plusnet.

However, sometime in the last week or two (I cannot place an exact day or time, but around the first week of February 2022) I have been experiencing very high latency spikes at relatively short intervals. This is most noticable while in meetings at work (I work from home) when my video and audio would pause/freeze for my colleagues trying to listen to me, and then extremely noticable in my online gaming experience when the game would have extreme rubber banding or just disconnecting from a server (this was in Rocket League). It's important to point out that these are all on ethernet connections.

I have since followed VM's advice and restarted my router, removed network switches, replaced cables, and factory reset the router. Nothing has fixed the latency issues. Even testing a direct router to ethernet cable to laptop connection yields the same latency issues. Since then I have set up a BQM (see below).

Every spike you see here is my boss asking me to repeat myself for the 3rd time, or my Rocket League team getting scored on because I missed a save where the ball teleported above my car.

I will post my router status logs in a reply to this thread. I've been lurking in this forum for a couple days and know that VM will often 'oversubscribe' an area. If someone in the community can have a look at this data and let me know if this is similar to that situation I would be very thankful. The one thing that seems odd to be is that if it were an oversubscription issue then I would think this issue would have gradually gotten worse, not the sudden shift that I have experienced.

I would also appreciate if someone at VM could take a look at this issue. I have raised a formal complaint and can provide a reference number if needed. I will keep the BQM running for at least the next 30 days.

[CabbagesVM]

Downstream bonded channels

Channel Frequency (Hz) Power (dBmV) SNR (dB) Modulation Channel ID

1	330750000	1.2	40	256 qam	25
2	202750000	1.7	40	256 qam	9
3	210750000	1.2	40	256 qam	10
4	218750000	1.5	40	256 qam	11
5	226750000	1.4	40	256 qam	12
6	234750000	1.4	40	256 qam	13
7	242750000	1.2	40	256 qam	14
8	250750000	1.4	40	256 qam	15
9	258750000	1.2	40	256 qam	16
10	266750000	1.5	40	256 qam	17
11	274750000	1.2	40	256 qam	18
12	282750000	1.2	40	256 qam	19
13	290750000	1.4	40	256 qam	20
14	298750000	1.4	40	256 qam	21
15	306750000	1.5	40	256 qam	22
16	314750000	1.4	40	256 qam	23
17	322750000	1.2	40	256 qam	24
18	338750000	1.5	40	256 qam	26
19	346750000	1.2	40	256 qam	27
20	354750000	1.4	40	256 qam	28
21	362750000	1	40	256 qam	29
22	370750000	0.5	40	256 qam	30
23	378750000	0.9	40	256 qam	31
24	386750000	0.5	40	256 qam	32

Downstream bonded channels

Channel Locked Status RxMER (dB) Pre RS Errors Post RS Errors

1	Locked	40.3	4	0
2	Locked	40.3	7	0
3	Locked	40.3	52	0
4	Locked	40.3	5	0
5	Locked	40.3	71	0
6	Locked	40.9	10	0
7	Locked	40.3	7	0
8	Locked	40.3	6	0
9	Locked	40.3	7	0
10	Locked	40.3	4	0
11	Locked	40.3	9	0
12	Locked	40.9	6	0
13	Locked	40.3	8	0
14	Locked	40.3	9	0
15	Locked	40.9	13	0
16	Locked	40.3	21	0
17	Locked	40.3	17	0
18	Locked	40.3	6	0
19	Locked	40.3	8	0
20	Locked	40.3	9	0
21	Locked	40.3	9	0
22	Locked	40.3	7	0
23	Locked	40.3	10	0
24	Locked	40.3	4	0

Upstream bonded channels

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

1	60300021	43.3	5120	64 qam	1
2	39400000	41.3	5120	64 qam	4
3	46200007	41.8	5120	64 qam	3
4	53700000	41.8	5120	64 qam	2

Upstream bonded channels

Channel Channel Type T1 Timeouts T2 Timeouts T3 Timeouts T4 Timeouts

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

 

[CabbagesVM]

Network Log

Time Priority Description

15/02/2022 21:55:41	notice	LAN login Success;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
15/02/2022 20:19:17	critical	No Ranging Response received - T3 time-out;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
15/02/2022 20:17:56	notice	LAN login Success;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
15/02/2022 00:15:24	critical	No Ranging Response received - T3 time-out;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
14/02/2022 22:35:19	notice	DHCP Renew - lease parameters tftp file-cmreg-vmdg505-bbt057+voc-b.cm modified;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
14/02/2022 22:35:19	Error	DHCP RENEW WARNING - Field invalid in response v4 option;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
12/02/2022 02:08:26	critical	No Ranging Response received - T3 time-out;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
11/02/2022 19:20:39	notice	LAN login Success;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
11/02/2022 00:26:57	critical	No Ranging Response received - T3 time-out;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
10/02/2022 22:11:9	notice	DHCP Renew - lease parameters tftp file-cmreg-vmdg505-bbt057+voc-b.cm modified;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
10/02/2022 22:11:9	Error	DHCP RENEW WARNING - Field invalid in response v4 option;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
08/02/2022 11:00:9	critical	No Ranging Response received - T3 time-out;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
07/02/2022 10:11:10	notice	DHCP Renew - lease parameters tftp file-cmreg-vmdg505-bbt057+voc-b.cm modified;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
07/02/2022 10:11:10	Error	DHCP RENEW WARNING - Field invalid in response v4 option;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
04/02/2022 07:37:39	critical	No Ranging Response received - T3 time-out;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
04/02/2022 00:43:42	notice	DHCP Renew - lease parameters tftp file-cmreg-vmdg505-bbt057+voc-b.cm modified;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
04/02/2022 00:43:42	Error	DHCP RENEW WARNING - Field invalid in response v4 option;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
31/01/2022 22:27:4	critical	No Ranging Response received - T3 time-out;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
31/01/2022 06:38:45	notice	DHCP Renew - lease parameters tftp file-cmreg-vmdg505-bbt057+voc-b.cm modified;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
31/01/2022 06:38:45	Error	DHCP RENEW WARNING - Field invalid in response v4 option;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;

[Andrew-G]

I'm afraid that looks very much like over-utilisation, and if it is the outlook is not good.

However, there are some faults that are amplified when the network is busy, and it's worth posting your hub status data for us to read the entrails.   Pull up the log in page for the hub.  But don't log in, just click on the link "Check router status"  That'll bring up a window with five tabs.  Open the Downstream tab.  Select all the text (Ctrl-A if using a keyboard), copy it (Ctrl-C), then paste it (Ctrl-V) into a reply here as TEXT not screenshots.  Post that, do the same for the Upstream and Network log.  You'll get an error message when you post the Network log, just click on "post" a second time.

It might be curable, but I'm not optimistic, and because of the way VM work you can't rely on the company to admit if there's is a utilisation problem.  If the problem either hasn't been investigated, or if it has but doesn't pass VM's very high bar, then agents have to say "all looks good from our side" or "we've checked the circuit and there's no utilisation fault showing on the system". 

[CabbagesVM]

You must have posted just before I posted the router status data. Have a look at the Downstream, Upstream, and Network log above your reply and let me know what you think.

Can over-utilisation just suddenly start causing issues? I feel like it was a flip being switched rather than a slow reveal.

[jem101]

@CabbagesVM the hub stats you posted are fine, as @Andrew-G says, this does have all the hallmarks of over utilisation in your local area. Now if this is indeed the case then there is nothing you can do, change hub, own router, cabled via wireless - the issue is upstream of you and isn't something you can effect.

An analogy would be a road, the hub stats give the status of the road surface, all is good, no potholes, no roadworks. But if the road is congested, too many cars on it, then no amount of 'fixing' the road will do anything - you need 'more road'. And increasing capacity, is neither cheap, nor sometimes, even possible 

[CabbagesVM]

Is this considered acceptable to the regulator? I've learned the hard way with energy providers that I must go through an official complaints process from the outset of an issue. So for this I've immediately initiated this with VM and will be collecting evidence. After which I will at the earliest opportunity escalate to CISAS if this is not fixed. 

Can CISAS force VM to release me from my contract early without incurring a fee for an issue such as this? This affects my livelihood, both in my day job, and my leisure time and it cannot continue for an extended period.

[Andrew-G]

When you took the hub status data it was particularly good, suggesting the quality of your cable connection is excellent, and that the problems sit at the head of the local HFC or FTTP network - that's normally where the pinch point is that causes over-utilisation, because the CMTS can't process the traffic fast enough at peak times, packets get briefly queued, and that queuing is what causes the latency to spike, causing problems for games, video and voice calls, live streaming and other related problems.

CISAS can and will order VM to release you from contract if the problem is not resolved and you state that as an acceptable outcome (along with compensation).  The process operates in a similar to the way Energy Ombudsman scheme, and just like energy complaints, VM seem spectacularly bad at their handling complaints that they could resolve themselves.

Ofcom as regulator could impose punishments on VM for over-subscribing their network, but are utterly useless and do little other than count complaints.  In fact Ofcom are so staggering useless, that they don't even bother to enforce their own Fairness Code that is routinely breached by VM and probably some other companies.  To be fair to VM, they have done and continue to do a lot to increase capacity, but where they refuse to admit problems early, and refuse to  truthfully explain if anything and when anything will done to fix the problem customers in these situations are left with a poor quality service and no idea if VM will ever fix it.  The gift to changing that sits entirely with VM's management voluntarily, or Ofcom to break a few fingers until the company volunteer it, I see neither outcome as likely in the foreseeable future.

[CabbagesVM]

Thank you for your insight, I will keep all of this in mind throughout the complaint process. It will be more of a faff since I can't use a service like Resolver to keep track of things. They have booked an engineer appointment (although I've yet to receive any confirmation over email for this) for Tuesday evening via the Whatsapp messaging service. What should I expect on the day for the engineer to do? Is there anyway I can prep things to ensure that it is very obvious to the engineer that there are no issues with my setup? I really don't want them leaving having concluded there is no issue.

[Andrew-G]

Resolver is a poor way of dealing with complaints IMHO since you're involving a third party who adds little other than simple interface, but if you want to try it then don't let me stop you.

Technician will check power levels, connections, any evidence of noise, might even swap the hub.  Nothing you need to do to prepare (other than ensuring the hub is accessible).  A very good chance the technician will find nothing amiss if this is over-utilisation.  Sometimes they'll comment on utilisation issues they know of, sometimes they either won't comment or won't know.  Many seem unfamiliar with tools like a BQM.