on 06-06-2022 22:42
I've been experiencing high ping spikes during peak hours (looking at my BQMs it's basically at any time not in the middle of the night!) - an engineer came to check the line for signal issues and replaced my hub but the issue persists - he suggested it's a network issue (and it definitely looks like some sort of contention to me)
This is verging on unplayable at times - the engineer said he'd flag this as a possible network issue but I would like to get some kind of indication that it's being looked into, as it's been ongoing for several months now.
on 07-06-2022 13:52
Your BQM suggests over utilisation.
However Post the power levels, Pre and PostRS errors and network log from the Hub. Once done we can comment.
I'm a Very Insightful Person, I'm here to share knowledge, I don't work for Virgin Media. Learn more
Have I helped? Click Mark as Helpful Answer or use Kudos to say thanks
on 07-06-2022 19:34
Channel Frequency (Hz) Power (dBmV) SNR (dB) Modulation Channel ID
1 | 723000000 | 2.5 | 38 | 256 qam | 40 |
2 | 539000000 | 3.2 | 38 | 256 qam | 17 |
3 | 547000000 | 3 | 38 | 256 qam | 18 |
4 | 555000000 | 3.2 | 38 | 256 qam | 19 |
5 | 563000000 | 3.2 | 38 | 256 qam | 20 |
6 | 571000000 | 3 | 38 | 256 qam | 21 |
7 | 579000000 | 2.9 | 38 | 256 qam | 22 |
8 | 587000000 | 2.9 | 38 | 256 qam | 23 |
9 | 595000000 | 3 | 38 | 256 qam | 24 |
10 | 603000000 | 3.2 | 38 | 256 qam | 25 |
11 | 611000000 | 3.2 | 38 | 256 qam | 26 |
12 | 619000000 | 3.2 | 38 | 256 qam | 27 |
13 | 627000000 | 3 | 38 | 256 qam | 28 |
14 | 635000000 | 2.9 | 38 | 256 qam | 29 |
15 | 643000000 | 2.5 | 38 | 256 qam | 30 |
16 | 651000000 | 2.5 | 38 | 256 qam | 31 |
17 | 659000000 | 2.5 | 38 | 256 qam | 32 |
18 | 667000000 | 2.5 | 38 | 256 qam | 33 |
19 | 675000000 | 2.7 | 38 | 256 qam | 34 |
20 | 683000000 | 3 | 38 | 256 qam | 35 |
21 | 691000000 | 2.9 | 38 | 256 qam | 36 |
22 | 699000000 | 3 | 38 | 256 qam | 37 |
23 | 707000000 | 2.9 | 38 | 256 qam | 38 |
24 | 715000000 | 2.5 | 38 | 256 qam | 39 |
Channel Locked Status RxMER (dB) Pre RS Errors Post RS Errors
1 | Locked | 38.9 | 1416 | 0 |
2 | Locked | 38.6 | 253 | 0 |
3 | Locked | 38.9 | 318 | 0 |
4 | Locked | 38.6 | 327 | 0 |
5 | Locked | 38.6 | 353 | 0 |
6 | Locked | 38.6 | 423 | 0 |
7 | Locked | 38.6 | 574 | 0 |
8 | Locked | 38.6 | 571 | 0 |
9 | Locked | 38.9 | 609 | 0 |
10 | Locked | 38.9 | 554 | 0 |
11 | Locked | 38.6 | 669 | 0 |
12 | Locked | 38.6 | 638 | 0 |
13 | Locked | 38.9 | 878 | 0 |
14 | Locked | 38.6 | 1005 | 0 |
15 | Locked | 38.6 | 1248 | 0 |
16 | Locked | 38.6 | 1187 | 0 |
17 | Locked | 38.6 | 1272 | 0 |
18 | Locked | 38.6 | 1443 | 0 |
19 | Locked | 38.6 | 1354 | 0 |
20 | Locked | 38.6 | 1387 | 0 |
21 | Locked | 38.9 | 1498 | 0 |
22 | Locked | 38.9 | 1454 | 0 |
23 | Locked | 38.6 | 1608 | 0 |
24 | Locked | 38.6 | 1665 | 0 |
Channel Frequency (Hz) Power (dBmV) Symbol Rate (ksps) Modulation Channel ID
1 | 53700000 | 44.8 | 5120 | 64 qam | 10 |
2 | 39400000 | 44.8 | 5120 | 64 qam | 12 |
3 | 46200000 | 44.8 | 5120 | 64 qam | 11 |
4 | 60300000 | 44.8 | 5120 | 64 qam | 9 |
Channel Channel Type T1 Timeouts T2 Timeouts T3 Timeouts T4 Timeouts
1 | ATDMA | 0 | 0 | 2 | 0 |
2 | ATDMA | 0 | 0 | 2 | 0 |
3 | ATDMA | 0 | 0 | 1 | 0 |
4 | ATDMA | 0 | 0 | 3 | 0 |
on 07-06-2022 22:56
Need to see the Network log as there are a lot of T3 errors.
I'm a Very Insightful Person, I'm here to share knowledge, I don't work for Virgin Media. Learn more
Have I helped? Click Mark as Helpful Answer or use Kudos to say thanks
on 08-06-2022 20:28
I suspect the initial errors are when the new hub was initially syncing (given the 1970 timestamp)
Time Priority Description
07/06/2022 19:31:41 | notice | LAN login Success;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0; |
06/06/2022 23:30:30 | critical | No Ranging Response received - T3 time-out;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0; |
06/06/2022 19:23:48 | notice | LAN login Success;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0; |
06/06/2022 04:23:39 | critical | No Ranging Response received - T3 time-out;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0; |
06/06/2022 01:02:52 | notice | DHCP Renew - lease parameters tftp file-cmreg-vmdg505-bbt060+voc-b.cm modified;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0; |
06/06/2022 01:02:52 | Error | DHCP RENEW WARNING - Field invalid in response v4 option;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0; |
02/06/2022 15:49:22 | critical | No Ranging Response received - T3 time-out;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0; |
02/06/2022 13:02:51 | notice | DHCP Renew - lease parameters tftp file-cmreg-vmdg505-bbt060+voc-b.cm modified;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0; |
02/06/2022 13:02:51 | Error | DHCP RENEW WARNING - Field invalid in response v4 option;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0; |
02/06/2022 12:04:17 | notice | DHCP Renew - lease parameters tftp file-cmreg-vmdg505-bbt060+voc-b.cm modified;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0; |
02/06/2022 12:04:17 | Error | DHCP RENEW WARNING - Field invalid in response v4 option;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0; |
02/06/2022 11:42:26 | notice | LAN login Success;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0; |
02/06/2022 11:34:44 | notice | SW download Successful - Via Config file |
02/06/2022 11:31:44 | notice | SW Download INIT - Via Config file |
01/01/1970 00:02:1 | critical | No Ranging Response received - T3 time-out;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0; |
23/01/2020 03:48:5 | critical | SYNC Timing Synchronization failure - Loss of Sync;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.0;CM-VER=3.0; |
01/01/1970 00:01:56 | critical | 16 consecutive T3 timeouts while trying to range on upstream channel 2;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0; |
01/01/1970 00:01:56 | critical | Ranging Request Retries exhausted;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0; |
01/01/1970 00:01:49 | critical | No Ranging Response received - T3 time-out;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0; |
01/01/1970 00:01:48 | critical | 16 consecutive T3 timeouts while trying to range on upstream channel 3;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0; |
on 09-06-2022 08:00
Seems over-utilisation is the cause.
The BQM you posted shows a typical over-utilisation pattern, meaning more traffic than VM's local network can handle. The particular giveaway is the way that latency magically improves at half past midnight, and then builds again through working hours to a worst case usually in the 7pm-11pm slot when the network it typically busiest.
Nothing you can do to improve matters. In some areas VM undertake work to rejig the local networks to balance loads and eliminate over-utilisation. But sometimes/often that's either not possible, or judged uneconomic if there's a need to spend money on more equipment. And sadly VM won't ever admit the truth, so even where there is a fault reference and a "fix date", but there's no way of knowing if that fix date is actually backed by an actual plan of action and programme of works. Quite often it seems quoted fix dates are simple unabashed lies, and as the fix date approaches it is simply moved a month or two ahead. It is possible your area will be in line for improvement, but there's no way of finding out. So, if the problem persists you have two simple options:
1) Sit it out, and hope that either VM do carry out improvement works. There's little or nothing you can do to force VM to upgrade the network, nor to be honest about the outlook. This has been the case for years now, although the actual incidence of over-utilisation has diminished over time as VM have fixed the worst problems (no help to you, of course).
2) Get yourself a new ISP. If you're in a fixed term contract you'll probably have to use the VM complaints process (and almost certainly escalate for arbitration at CISAS ) to be released from contract without penalty. If you need to do this, the grounds of your complaint is the poor performance, and your request fro release from contract without penalty is twofold: First the Consumer Rights Act 2015 that requires any consumer service to be provided with "reasonable skill and care", and second, the Ofcom Fairness Commitments, that state "Customers’ services work as promised, reliably over time. If things go wrong providers give a prompt response to fix problems and take appropriate action to help their customers, which may include providing compensation where relevant. If providers can’t fix problems with core services they have promised to deliver within a reasonable period, customers can walk away from their contract with no penalty."
on 11-06-2022 17:47
Good Afternoon @QmunkE, thanks for your post and I'm sorry to hear of the issues you've currently experiencing in your local area.
Can you please advise us if the issues you're currently experiencing are still ongoing, and if so, when did these issues begin?
Did you possibly discuss high utilisation with the engineer that has recently visited your property?
Kindest regards,
David_Bn
on 12-06-2022 15:14
Yes, still ongoing, and has been for several months.
Yes, discussed with the engineer and he said he'd flag this as a potential network issue.
on 14-06-2022 15:57
Hi QmunkE
Sorry to hear this is still ongoing for you. I have checked the systems at our side and cannot see issues with your services personally. They engineer would have flagged this to Networks who will be monitoring the area. Hopefully this will be resolved soon for you. Please let us know if you are having any further issues or have any questions at all. We'll be here to help on the community forums if needed :).