Is this typical Virgin Media jitter ?

[webBeAsTspider]

Hi,

As a previous BT user I did spend quite some time looking at their network, their jitter was low +/- 1ms, now via Virgin Media I'm seeing some not very good jitter, typically +10ms or more, is this typical with perhaps a over loaded network ? I'm using a wired network, there's nothing happening on my network, 1 user - myself and wireshark shows nothing happening apart from ping.

ping to first hop

Reply from 86.28.83.173: bytes=32 time=10ms TTL=62
Reply from 86.28.83.173: bytes=32 time=8ms TTL=62
Reply from 86.28.83.173: bytes=32 time=17ms TTL=62 <<<<<<<<
Reply from 86.28.83.173: bytes=32 time=8ms TTL=62
Reply from 86.28.83.173: bytes=32 time=8ms TTL=62
Reply from 86.28.83.173: bytes=32 time=8ms TTL=62
Reply from 86.28.83.173: bytes=32 time=8ms TTL=62
Reply from 86.28.83.173: bytes=32 time=7ms TTL=62
Reply from 86.28.83.173: bytes=32 time=9ms TTL=62

ping to bbc.co.uk

Reply from 151.101.128.81: bytes=32 time=12ms TTL=58
Reply from 151.101.128.81: bytes=32 time=14ms TTL=58
Reply from 151.101.128.81: bytes=32 time=12ms TTL=58
Reply from 151.101.128.81: bytes=32 time=16ms TTL=58
Reply from 151.101.128.81: bytes=32 time=13ms TTL=58
Reply from 151.101.128.81: bytes=32 time=20ms TTL=58 <<<<<<<<<<<<<<
Reply from 151.101.128.81: bytes=32 time=14ms TTL=58
Reply from 151.101.128.81: bytes=32 time=13ms TTL=58
Reply from 151.101.128.81: bytes=32 time=13ms TTL=58

tracert to bbc.co.uk

1 1 ms 1 ms 2 ms 192.168.0.1
2 11 ms 16 ms 8 ms 10.53.37.117
3 9 ms 12 ms 9 ms nott-core-2b-xe-305-0.network.virginmedia.net [86.28.83.173]
4 * * * Request timed out.
5 16 ms 16 ms 13 ms tcl5-ic-5-ae0-0.network.virginmedia.net [62.254.84.66]
6 14 ms 13 ms 14 ms 157.52.127.10
7 13 ms 13 ms 12 ms 151.101.192.81

[Andrew-G]

It is entirely possible that your performance is normal for a VM DOCSIS connection.  DOCSIS is an analogue radio frequency technology, it is prone to a range of issues that most readily manifest in variable latency, sometimes these are within normal ranges, sometimes they're not.  And as a general rule, any DOCSIS connection even in ideal conditions will have more variability of latency than an Openreach connection.

When the latency of a VM connection is abnormal, there's three types of problem: (i) Easily resolved, usually basic power level or noise faults, (ii) Not-easily resolved, CBU faults where customers have to make themselves a real pain before the problem gets fixed, and (iii) Not likely to be resolved, usually because VM know the fault but deem it uneconomic to fix, particularly in over-utilisation circumstances.  The first of these are most common.

My preferred tool to see what's going on with a VM connection is a Broadband Quality Monitor to show what's going on with your VM connection.  Post a LINK to a LIVE, SHARED graph here and we'll see what's happening.  Usually needs to run for 24 hours before we can draw reasonable conclusions, but the live graph will continuously update so you can post the link immediately.  If using one you already have setup, check that your current IP address is the same as one the BQM is using - VM IP addresses are usually sticky, but they can and do change. 

In the meanwhile you could post the hub's status data for a quick check on that: 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.  Then we can check for any obvious problems with power, noise or error counts.

[webBeAsTspider]

Thanks for the reply, I don't know much about VM modems but as below nothing is jumping out at me, all looks fairly uniform, I'll setup a BQM and post back tomorrow. I'm suspecting it's just conjestion, it's not causing any major problems just would be nice if the jitter was lower.

3.0 Downstream channels
Channel Frequency (Hz) Power (dBmV) SNR (dB) Modulation Channel ID
26 339000000 4.599998 40.366287 QAM256 26
1 139000000 -2.400002 36.609653 QAM256 1
2 147000000 -2.000000 37.355988 QAM256 2
3 155000000 -1.599998 37.092701 QAM256 3
4 163000000 -1.000000 37.636276 QAM256 4
5 171000000 -0.500000 37.636276 QAM256 5
6 179000000 -0.299999 38.605377 QAM256 6
7 187000000 0.099998 38.983261 QAM256 7
8 195000000 0.200001 38.605377 QAM256 8
9 203000000 0.400002 38.605377 QAM256 9
10 211000000 0.700001 38.605377 QAM256 10
11 219000000 0.900002 38.983261 QAM256 11
12 227000000 1.099998 38.605377 QAM256 12
13 235000000 1.099998 38.983261 QAM256 13
14 243000000 0.900002 38.983261 QAM256 14
15 251000000 0.900002 38.983261 QAM256 15
16 259000000 0.799999 38.605377 QAM256 16
17 267000000 0.799999 38.983261 QAM256 17
18 275000000 1.599998 38.983261 QAM256 18
19 283000000 2.200001 38.605377 QAM256 19
20 291000000 2.700001 38.983261 QAM256 20
21 299000000 2.900002 38.605377 QAM256 21
22 307000000 3.000000 38.983261 QAM256 22
23 315000000 3.500000 38.983261 QAM256 23
24 323000000 3.900002 38.983261 QAM256 24
25 331000000 4.400002 38.983261 QAM256 25
27 347000000 4.699997 40.366287 QAM256 27
28 355000000 4.900002 38.983261 QAM256 28
29 363000000 4.800003 40.366287 QAM256 29
30 371000000 4.699997 38.983261 QAM256 30
31 379000000 4.500000 38.983261 QAM256 31

3.0 Downstream channels
Channel Lock Status RxMER (dB) Pre RS Errors Post RS Errors
26 Locked 40.366287 0 0
1 Locked 36.609653 0 0
2 Locked 37.355988 0 0
3 Locked 37.092701 0 0
4 Locked 37.636276 0 0
5 Locked 37.636276 1 0
6 Locked 38.605377 0 0
7 Locked 38.983261 0 0
8 Locked 38.605377 0 0
9 Locked 38.605377 0 0
10 Locked 38.605377 0 0
11 Locked 38.983261 0 0
12 Locked 38.605377 0 0
13 Locked 38.983261 0 0
14 Locked 38.983261 0 0
15 Locked 38.983261 0 0
16 Locked 38.605377 0 0
17 Locked 38.983261 0 0
18 Locked 38.983261 0 0
19 Locked 38.605377 0 0
20 Locked 38.983261 0 0
21 Locked 38.605377 0 0
22 Locked 38.983261 0 0
23 Locked 38.983261 0 0
24 Locked 38.983261 0 0
25 Locked 38.983261 0 0
27 Locked 40.366287 0 0
28 Locked 38.983261 0 0
29 Locked 40.366287 0 0
30 Locked 38.983261 0 0
31 Locked 38.983261 0 0

3.1 Downstream channels
Channel Channel Width (MHz) FFT Type Number of Active Subcarriers Modulation (Active Profile) First Active Subcarrier (Hz)
159 96 4K 1880 QAM4096 759

3.1 Downstream channels
Channel ID Lock Status RxMER Data (dB) PLC Power (dBmV) Correcteds (Active Profile) Uncorrectables (Active Profile)
159 Locked 41 5.7 10675071 1

--------------------------------------------

3.0 Upstream channels
Channel Frequency (Hz) Power (dBmV) Symbol Rate (ksps) Modulation Channel ID
1 60300000 43.270599 5120 KSym/sec 64QAM 1
2 39400000 41.270599 5120 KSym/sec 64QAM 4
3 46200000 41.770599 5120 KSym/sec 64QAM 3
4 53700000 42.270599 5120 KSym/sec 64QAM 2

3.0 Upstream channels
Channel Channel Type T1 Timeouts T2 Timeouts T3 Timeouts T4 Timeouts
1 US_TYPE_STDMA 0 0 0 0
2 US_TYPE_STDMA 0 0 0 0
3 US_TYPE_STDMA 0 0 1 0
4 US_TYPE_STDMA 0 0 0 0

[Andrew-G]

Data shows the downstream power levels have too wide a range.  I've flagged for forum staff to comment, they will probably want to book a technician visit to sort that out.

[gitty]

It seems like normal behavior. Two things contribute to latency and jitter at the DOCSIS layer: Queueing delay (often used in the context of bufferbloat) and media acquisition delay (delay between wanting to transmit something and getting permission to transmit).

The upcoming Low Latency DOCSIS will improve both (and when implemented by VM).

[Tom_W1]

Hi @webBeAsTspider thanks for your post although I'm sorry to hear of your concerns raised.

I'm more than happy to book a technician for you with the downstream levels showing too wide a range, as @Andrew-G has suggested.

I'm going to drop you a PM to ask you to confirm some security details so I can book this in for you.

Please expect this PM to arrive shortly and respond when you can! 
Many thanks

[legacy1]

This "downstream levels showing too wide a range" will likely not cause a problem or improve things if fixed VM downstream jitter is pretty good the upstream will show jitter this can be +10ms with the average being low unless impacted by utilisation. 

[gitty]

To name another: The first/x hop is not built to be pinged, so it could result in higher jitter, compared to other ping targets.

legacy1 is right regarding the RF. As long as the signal is good enough to be understood (no codeword errors), a "better" signal won't matter.

[webBeAsTspider]

Yes I agree the various routers may not be good ping targets, I see the same jitter though to places such as bbc.co.uk, I used bbc.co.uk when I was with BT so I know it normally should give tight ping variation.

Still might be worth getting my power levels sorted and a general health check, it's an old property, I suspect VM has been installed a long time ago.

I have replaced one of the isolators (upstairs) as the old one was rusty and I've removed the isolator from the down stairs connection, that was also rusty and not in a good state. I get plenty of download speed, more or less wire speed at 1G and the usual 50Mb up, so the connection seems solid.

I have noticed when logged into work via a VPN I get reconnects every 2 to 4 hours that never used to happen when with BT, I'm not sure what that is i.e. whether the VPN loses sync and / or the hub4 has some issue, it reconnects real quick.

[legacy1]

---

@webBeAsTspider wrote:

I have noticed when logged into work via a VPN I get reconnects every 2 to 4 hours that never used to happen when with BT, I'm not sure what that is i.e. whether the VPN loses sync and / or the hub4 has some issue, it reconnects real quick.

---

Your own router could solve that with hub in modem mode