on 24-07-2023 16:07
I've been with Virgin Media in this house for 10 years. There was a period of instability when we upgraded to 1 Gig a couple of years ago but it has generally been pretty reliable. The last couple of months it has been up and down like a yoyo. Below is the trace from today. I'm at a loss as to what is causing it and unfortunately I think I'm either going to have to downgrade in search of stability or switch provider.
The SNR and power levels all look fine:
The only entries in the log looks fairly innocuous:
Any suggestions? I have the had the router in bridge mode connected to a Unifi Dream Machine Pro which has generally been rock solid so I don't think its that.. but open to suggestions...
Answered! Go to Answer
26-07-2023 17:43 - edited 26-07-2023 17:49
VM's last firmware release for the Hub 4 was quite blooper, we no longer get to see any Pre or Post RS errors for the 3.0 DOCSIS Downstream channels.
But in the 3.1 DOCSIS channels we do see a massive clue as to the issue, the stats show over 19 Million Pre RS errors have occurred and Zero Post RS errors. Zero - You can not be serious ! That is another Hub 4 firmware blooper.
In short is looks like a serious SNR ( line noise ) issue has been occurring in your locality.
Often via 0800 561 61 we can get info about know faults in our street & progress to fix.
on 24-07-2023 16:22
Oh I guess the network log needs to be text so it can be anonymised...
Mon 24/07/2023 12:26:19 | 6 | US profile assignment change. US Chan ID: 6; Previous Profile: 11; New Profile: 12.;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.1; |
Mon 24/07/2023 12:26:18 | 5 | DBC-REQ Mismatch Between Calculated Value for P1.6hi Compared to CCAP Provided Value;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.1; |
Mon 24/07/2023 12:26:03 | 5 | MIMO Event MIMO: Stored MIMO=-1 post cfg file MIMO=-1;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.1; |
Mon 24/07/2023 12:17:52 | 4 | DBC-ACK not received;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.1; |
Mon 24/07/2023 12:17:50 | 6 | US profile assignment change. US Chan ID: 6; Previous Profile: ; New Profile: 11.;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.1; |
Mon 24/07/2023 12:10:56 | 6 | DHCP Renew - lease parameters tftp file-cmreg-vmdg640-bbt076-b.cm modified;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.1; |
Mon 24/07/2023 12:10:56 | 4 | DHCP RENEW WARNING - Field invalid in response v4 option;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.1; |
Mon 24/07/2023 12:06:50 | 3 | No Ranging Response received - T3 time-out;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.1; |
Mon 24/07/2023 11:45:50 | 4 | DBC-ACK not received;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.1; |
Mon 24/07/2023 11:45:48 | 6 | US profile assignment change. US Chan ID: 6; Previous Profile: 11; New Profile: 12.;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.1; |
Mon 24/07/2023 11:12:43 | 4 | DBC-ACK not received;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.1; |
Mon 24/07/2023 11:12:41 | 6 | US profile assignment change. US Chan ID: 6; Previous Profile: 12; New Profile: .;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.1; |
Mon 24/07/2023 11:11:16 | 4 | DBC-ACK not received;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.1; |
Mon 24/07/2023 10:08:51 | 6 | US profile assignment change. US Chan ID: 6; Previous Profile: 11; New Profile: 12.;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.1; |
Mon 24/07/2023 10:07:26 | 4 | DBC-ACK not received;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.1; |
Mon 24/07/2023 09:36:27 | 6 | US profile assignment change. US Chan ID: 6; Previous Profile: ; New Profile: 12.;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.1; |
Mon 24/07/2023 09:35:02 | 4 | DBC-ACK not received;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.1; |
Mon 24/07/2023 08:33:06 | 6 | US profile assignment change. US Chan ID: 6; Previous Profile: ; New Profile: 11.;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.1; |
Mon 24/07/2023 08:33:06 | 5 | TCS Partial Service;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.1; |
Mon 24/07/2023 08:33:06 | 5 | DBC-REQ Mismatch Between Calculated Value for P1.6hi Compared to CCAP Provided Value;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.1; |
Mon 24/07/2023 08:32:53 | 5 | TCS Partial Service;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.1; |
Mon 24/07/2023 08:32:53 | 5 | DBC-REQ Mismatch Between Calculated Value for P1.6hi Compared to CCAP Provided Value;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.1; |
Mon 24/07/2023 08:31:58 | 3 | No Ranging Response received - T3 time-out;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.1; |
Mon 24/07/2023 08:31:52 | 4 | DBC-ACK not received;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.1; |
Mon 24/07/2023 08:31:50 | 5 | TCS Partial Service;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.1; |
Mon 24/07/2023 08:31:47 | 3 | No Ranging Response received - T3 time-out;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.1; |
Mon 24/07/2023 08:31:47 | 3 | Unicast Ranging Received Abort Response - initializing MAC;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.1; |
Mon 24/07/2023 08:31:43 | 3 | No Ranging Response received - T3 time-out;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.1; |
Mon 24/07/2023 08:30:49 | 4 | DBC-ACK not received;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.1; |
Mon 24/07/2023 07:58:58 | 6 | US profile assignment change. US Chan ID: 6; Previous Profile: 11; New Profile: 12.;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.1; |
Mon 24/07/2023 07:28:25 | 5 | DBC-REQ Mismatch Between Calculated Value for P1.6hi Compared to CCAP Provided Value;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.1; |
Mon 24/07/2023 07:27:24 | 4 | DBC-ACK not received;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.1; |
Mon 24/07/2023 07:27:22 | 5 | DBC-REQ Mismatch Between Calculated Value for P1.6hi Compared to CCAP Provided Value;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.1; |
Mon 24/07/2023 07:26:21 | 4 | DBC-ACK not received;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.1; |
Mon 24/07/2023 07:25:31 | 6 | US profile assignment change. US Chan ID: 6; Previous Profile: 12; New Profile: .;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.1; |
Mon 24/07/2023 06:42:47 | 4 | DBC-ACK not received;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.1; |
Mon 24/07/2023 06:42:44 | 6 | US profile assignment change. US Chan ID: 6; Previous Profile: 12; New Profile: .;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.1; |
Mon 24/07/2023 06:42:18 | 4 | DBC-ACK not received;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.1; |
on 24-07-2023 16:25
Hi mfarrugia
Your photo showing the network log was rejected due it showing your MAC addresses. You should post that information again, but this time copy/paste the info rather than a photo. The forum will then automatically blank out the MAC addresses. ( It's actually better to copy/paste all stats when adding them to the forum as that method makes it easier to read )
The actual stats themselves look very good although your BQM doesn't look very good at all. It may be due to local issues or internal cabling. Have you tried a different ethernet cable?
What is your speed like using https://samknows.com/realspeed/ (I find I get the best results using Edge browser)
It might also be an idea to put the hub into router mode for the speed test, and also leave it in router mode for an hour or two when possible to see if the BQM improves.
There might also be local issues. Have you used the /check-services/i function? You can also a run a test on your equipment from there.
If nothing is showing you could also try the automated Service Status number 0800 561 0061. This often gives details of more local issues down to postcode level.
on 25-07-2023 08:51
Hi mfarrugia,
Thanks for your post and welcome back to the community.
Sorry to see that you're experiencing issues with your broadband, just from checking our service however I can see that you're currently affected by an area fault.
The fault has an estimated fix time of 26th July at 6pm.
Apologies for the inconvenience at this time as our team will be working to get this matter resolved for you.
Regards,
on 26-07-2023 17:28
This did indeed fix the problem. Is there any way to find out what the root cause was? The connection has been extremely unstable for the last couple of months and every time I try to diagnose it with the online chat people they tell me they don't support my router being in bridge mode so won't investigate it 😕
26-07-2023 17:43 - edited 26-07-2023 17:49
VM's last firmware release for the Hub 4 was quite blooper, we no longer get to see any Pre or Post RS errors for the 3.0 DOCSIS Downstream channels.
But in the 3.1 DOCSIS channels we do see a massive clue as to the issue, the stats show over 19 Million Pre RS errors have occurred and Zero Post RS errors. Zero - You can not be serious ! That is another Hub 4 firmware blooper.
In short is looks like a serious SNR ( line noise ) issue has been occurring in your locality.
Often via 0800 561 61 we can get info about know faults in our street & progress to fix.
on 27-07-2023 08:44
Hi Client62,
So the "Correcteds (Active Profile)" column is essentially Pre RS errors on the DOCSIS 3.1 channels? If so then I do indeed still have an SNR issue. The router rebooted again this morning and when I called 0800 561 61 they said there is an intermittent area fault they are investigating (it is beyond infuriating that the status web page shows a green tick in our postcode at the same time). When I upgraded to 1Gig the signal was marginal, we had to remove a splitter inside the house to get it stable. I'm wondering if I should just downgrade to a speed that doesn't require DOCSIS 3.1? TBH at this stage, I need it stable more than I need the speed - its borderline unusable for working from home...
on 27-07-2023 09:36
Yes 3.1 Correcteds / Uncorrectable are the same as 3.0 Pre RS / Post RS. Event sticking to a consistent terms was too much to ask.
The 0800 561 0061 is the best place this get us down to street level.
The service status via the website needs significant planned maintenance a major blackout affecting 1000s of homes before anything reports in our area.
The question of downgrading is a difficult one, the Hub 3 is DOCSIS 3.0 only but the Hub 4 & 5 both use mixed DOCSIS 3.0 and 3.1. Given the way CATV / DOCSIS works changing package should not make the slightest difference to stability because unlike with ADSL / VDSL where a slow sync speed = greater stability, on the VM platform we all aim to connect at the same speed. The Hub has a bandwidth profile to regulate the speed to match our subscription.
See if stability returns once the remaining issues are resolved.
on 28-07-2023 13:35
Hi @mfarrugia thanks for your patience so far.
We just wanted to update here after checking your response - we've checked things over and unfortunately, the outage is still ongoing and the new estimated time of fix is 02 AUG 2023 14:10.
Please let us know if you're still having any further issues after this time and we can advise further.
Many thanks
28-07-2023 14:22 - edited 28-07-2023 14:25
@Client62 wrote:But in the 3.1 DOCSIS channels we do see a massive clue as to the issue, the stats show over 19 Million Pre RS errors have occurred and Zero Post RS errors. Zero - You can not be serious ! That is another Hub 4 firmware blooper.
That insane number is actually a valid number for OFDM. It takes just a single flipped bit to create a corrected codeword. The FEC is designed to handle a lot of flipped bits, in order to allow the operator to run very high modulation orders.
The log will report 16/24 event codes, if the modem is having trouble with some of the downstream modulation profiles.