Menu
Reply
Bondie563
  • 4
  • 0
  • 0
Joining in
785 Views
Message 1 of 10
Flag for a moderator

Large latentcy during peak hours

Hey all

Recently moved to Virgin early december, started off great but recent weeks things have just got worse and worse. Speeds are decent but I've had issues working from home, especially with VoIP which is really choppy. Ran a BQM today, which reveals that the average latency absolutely blasts up at around 9AM until the evening. Included below:

 

https://www.thinkbroadband.com/broadband/monitoring/quality/share/523f8d5a5f1c724f40c6357ff6ef5c577c...

 

I think its probably network congestion caused by others working from home, which is understandable but I'm now getting a worse service than I did from BT and I would not have switched had we known it would be this bad. Would be great if anyone here could share their thoughts, I work in Telecoms so have a bit of knowledge and should be able to carry out any other diagnostics that might be helpful. 

0 Kudos
Reply
MikeRobbo
  • 15.27K
  • 1.17K
  • 1.95K
Alessandro Volta
739 Views
Message 2 of 10
Flag for a moderator

Re: Large latentcy during peak hours

Can you please

Type 192.168.0.1 (192.168.100.1 in Modem mode) into your browser URL bar and press enter. 

Hub 2 & 3 When the page appears DO NOT LOG IN but click ‘Check Router Status’.

Hub 4 When the page appears LOG IN then Advanced Settings > Tools > Network Status.

Copy and paste the contents of the Downstream, Upstream, Configuration and Network Log tabs onto here, if you get a yellow / straw box warning click the Post button again. Use one post for each tab if you wish.

Please do not use screen grabs.

A Guru will be along soon to decipher the info.


*********************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************
BT Smart Hub 2 with 70Mbs Download,18Mbs Upload, 9.17ms Latency & 0.35ms Jitter.
0 Kudos
Reply
Bondie563
  • 4
  • 0
  • 0
Joining in
705 Views
Message 3 of 10
Flag for a moderator

Re: Large latentcy during peak hours

Downstream 

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

11630000005.538256 qam4
2139000000638256 qam1
3147000000638256 qam2
41550000005.838256 qam3
51710000005.438256 qam5
6179000000538256 qam6
71870000004.938256 qam7
81950000004.638256 qam8
92030000004.438256 qam9
102110000004.138256 qam10
112190000004.138256 qam11
12227000000438256 qam12
132350000003.738256 qam13
142430000003.538256 qam14
152510000003.238256 qam15
162590000003.238256 qam16
172670000003.738256 qam17
18275000000438256 qam18
192830000004.338256 qam19
202910000004.538256 qam20
212990000004.538256 qam21
223070000004.538256 qam22
233150000004.438256 qam23
243230000004.338256 qam24



Downstream bonded channels

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

1Locked38.9270
2Locked38.6210
3Locked38.6220
4Locked38.6340
5Locked38.9310
6Locked38.6290
7Locked38.9200
8Locked38.9200
9Locked38.6110
10Locked38.9150
11Locked38.9180
12Locked38.6190
13Locked38.9210
14Locked38.9170
15Locked38.9120
16Locked38.9160
17Locked38.9100
18Locked38.6180
19Locked38.6150
20Locked38.940
21Locked38.9170
22Locked38.9240
23Locked38.9140
24Locked38.9180

 

Upstream:

Upstream bonded channels

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

14620000044.5512064 qam3
23940000043512064 qam4
35370000044.5512064 qam2
46030000044.5512064 qam1



Upstream bonded channels

Channel Channel Type T1 Timeouts T2 Timeouts T3 Timeouts T4 Timeouts

1ATDMA0000
2ATDMA0010
3ATDMA0000
4ATDMA0010

 

 

0 Kudos
Reply
Bondie563
  • 4
  • 0
  • 0
Joining in
704 Views
Message 4 of 10
Flag for a moderator

Re: Large latentcy during peak hours

Configuration:

 

General Configuration

Network access
Allowed
Maximum Number of CPEs
1
Baseline Privacy
Enabled
DOCSIS Mode
Docsis30
Config file
iyewrkldJKDHSUBsgvca69834



Primary Downstream Service Flow

SFID550
Max Traffic Rate402500089
Max Traffic Burst42600
Min Traffic Rate0



Primary Upstream Service Flow

SFID549
Max Traffic Rate38500089
Max Traffic Burst42600
Min Traffic Rate0
Max Concatenated Burst42600
Scheduling TypeBestEffort

 

Network Log:

 

Network Log

Time Priority Description

05/01/2021 01:50:1criticalNo Ranging Response received - T3 time-out;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
03/01/2021 13:01:52noticeDHCP Renew - lease parameters tftp file-cmreg-vmdg505-bbt062-b.cm modified;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
03/01/2021 13:01:52ErrorDHCP RENEW WARNING - Field invalid in response v4 option;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
03/01/2021 12:44:32criticalNo Ranging Response received - T3 time-out;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
31/12/2020 01:01:51noticeDHCP Renew - lease parameters tftp file-cmreg-vmdg505-bbt062-b.cm modified;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
31/12/2020 01:01:51ErrorDHCP RENEW WARNING - Field invalid in response v4 option;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
28/12/2020 23:21:11criticalNo Ranging Response received - T3 time-out;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
27/12/2020 13:01:51noticeDHCP Renew - lease parameters tftp file-cmreg-vmdg505-bbt062-b.cm modified;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
27/12/2020 13:01:51ErrorDHCP RENEW WARNING - Field invalid in response v4 option;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
24/12/2020 18:36:49noticeDHCP Renew - lease parameters tftp file-cmreg-vmdg505-bbt062-b.cm modified;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
24/12/2020 18:36:49ErrorDHCP RENEW WARNING - Field invalid in response v4 option;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
22/12/2020 17:33:59noticeLAN login Success;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
21/12/2020 12:13:49criticalNo Ranging Response received - T3 time-out;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
20/12/2020 12:34:29noticeSW download Successful - Via Config file
20/12/2020 12:31:55noticeSW Download INIT - Via Config file
19/12/2020 18:27:5noticeDHCP Renew - lease parameters tftp file-cmreg-vmdg505-bbt062-b.cm modified;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
19/12/2020 18:27:5ErrorDHCP RENEW WARNING - Field invalid in response v4 option;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
16/12/2020 21:30:23criticalNo Ranging Response received - T3 time-out;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
16/12/2020 06:27:4noticeDHCP Renew - lease parameters tftp file-cmreg-vmdg505-bbt062-b.cm modified;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
16/12/2020 06:27:4ErrorDHCP RENEW WARNING - Field invalid in response v4 option;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;

 

Appreciate your help by the way mate

0 Kudos
Reply
MikeRobbo
  • 15.27K
  • 1.17K
  • 1.95K
Alessandro Volta
697 Views
Message 5 of 10
Flag for a moderator

Re: Large latentcy during peak hours

Your BQM is certainly showing signs of high (over) utilisation.

You only really have two choices, either sit it out for as long as it takes or try and get out of your contract without penalty so that you can move elsewhere.


*********************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************
BT Smart Hub 2 with 70Mbs Download,18Mbs Upload, 9.17ms Latency & 0.35ms Jitter.
0 Kudos
Reply
Bondie563
  • 4
  • 0
  • 0
Joining in
678 Views
Message 6 of 10
Flag for a moderator

Re: Large latentcy during peak hours

I appreciate your responses mate.

Wish we’d know this before the switch. I take it then that there’s no chance Virgin will be doing anything to rectify this? Will a member of virgin still take a look at this thread?

0 Kudos
Reply
MikeRobbo
  • 15.27K
  • 1.17K
  • 1.95K
Alessandro Volta
657 Views
Message 7 of 10
Flag for a moderator

Re: Large latentcy during peak hours

You can call it in as slow speeds and see what they say.

As for VM doing anything - that is like asking "how long is a piece of string" ?


*********************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************
BT Smart Hub 2 with 70Mbs Download,18Mbs Upload, 9.17ms Latency & 0.35ms Jitter.
0 Kudos
Reply
Andrew-G
  • 8.14K
  • 1.36K
  • 3.68K
Very Insightful Person
Very Insightful Person
632 Views
Message 8 of 10
Flag for a moderator

Re: Large latentcy during peak hours


@Bondie563 wrote:

I appreciate your responses mate.

Wish we’d know this before the switch. I take it then that there’s no chance Virgin will be doing anything to rectify this? Will a member of virgin still take a look at this thread?


The BQM shows a typical over-utilisation pattern, meaning more traffic than VM's local network can handle. You can choose to believe whether this is Covid related, or whether VM simply sell contracts until (and indeed after) the local network is at capacity, but the outcome is the same for now.

Nothing you can do to improve matters. In some areas VM do indeed 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 there will be 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 not, and as the fix date approaches it is simply moved a month or two ahead. Your 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.  The forum staff will eventually respond, and might be able to advise if there's a fault reference and an alleged fix date, but they can't see if there's a long history of previous fix dates that have come and gone, nor can they see if there's any planned works.  Read this for an example, and the follow on here.

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 states 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.

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

0 Kudos
Reply
audetto74
  • 143
  • 1
  • 17
Dialled in
626 Views
Message 9 of 10
Flag for a moderator

Re: Large latentcy during peak hours

Do you mind explaining which feature of the BQM indicates high utilisation.
I think I have the same issue, but not sure how to read it.
Thanks
0 Kudos
Reply
Andrew-G
  • 8.14K
  • 1.36K
  • 3.68K
Very Insightful Person
Very Insightful Person
562 Views
Message 10 of 10
Flag for a moderator

Re: Large latentcy during peak hours

@audetto74 You certainly did have an over-utilisation problem before, whether it's been fixed we'll see.  Best to start a new thread because "add-on" problems at the end of other people's threads are easily missed and it's difficult to offer differing advice to multiple people in the same thread.

But in answer to your question, a BQM shows primarily latency, which is the round-trip time in thousandths of a second for a test signal from Thinkbroadband's servers to your router and back to the server.  There's minimum, average and peak latency shown.  When an area has an over-utilisation problem, data gets queued for a few/many milliseconds at some pinch point, usually the Cable Modem Termination System that sits at the top end of the local coaxial cable network.  That CMTS translates all the radio-frequency signals from you and all your neighbours into digital optical signals that are pushed up a fibre optic link to VM's egress points to the real internet.

On a BQM, what any delays show up as is either continuous or frequent high peak latency, and if the delays are long enough then software will timeout and record a packet as lost (that's ANY red across the top of the graph).  A DOCSIS cable connection usually has a circa 19ms minimum latency, a 23ms average, and when working properly a small yellow fringe of peak latency results out to about 30ms.  What particularly marks out over-utilisation is when the peak latency shoots up to 70ms plus, often the minimum and average rise, and in bad cases there's packet loss as well....BUT because over-utilisation is caused by the amount of data traffic, between 12:30am and typically 8:00am, performance looks fine.  If there's also a noise problem you might see a few spikes through the early hours, that can often be resolved, but the over-utilisation won't be sorted by fixing a noise issue because the noise isn't causing the capacity issue.  Sometimes over-utilisation causes slow speeds up or down, but usually only in the worst cases - if a data packet has to wait 90ms en route, that won't materially affect measured speeds, but it will destroy latency-sensitive applications, such as VOIP and video calls, and gaming. 

If I "borrow" @Cozyman 's BQM you can see this quite clearly.  Sometimes the BQM can be much worse, sometimes a little better, but the defining characteristic of over-utilisation is that latency deteriorates during waking hours, with a peak between 4:00pm and 11:00pm, and then improves to normality during the small hours of the morning.  A day-and-night difference, if you like.  

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