on 16-02-2022 21:22
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.
on 16-02-2022 21:27
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 |
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 |
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 |
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 |
on 16-02-2022 21:27
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; |
on 16-02-2022 21:35
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".
on 16-02-2022 21:50
on 16-02-2022 22:54
@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
on 16-02-2022 23:16
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.
17-02-2022 07:03 - edited 17-02-2022 07:08
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.
on 17-02-2022 10:10
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.
on 17-02-2022 10:30
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.