Virgin Media Community

[adhsmith]

Hi there,

I have recently moved from Sky FTTC 160/30 G. Fast product to VMs 660/45, bandwidth wise VM has been spot on.

Foolishly I guess I expected the higher bandwidth network to be the faster more responsive network with respect to latency.

For a time I had Sky and VM side by side and on VPN to my office in Germany I was seeing 38-40ms on Sky but with VM on my VPN to the office and in fact on any tests in general it is 10-15ms worse, whilst it is not the end of the world I can still work productively and gaming pings have been acceptable, I'm no pro, but I would like to confirm this is an expected byproduct of running VMs older infrastructure and not an actual issue with my VM install.

I'm running a Hub4 and have tried it in and out of modem mode, modem mode doesn't improve things to any noticeable degree.

Is there anything I should look at or is it just what it is?

[Andrew-G]

That is indeed how things are.  DOCSIS (the technology for cable internet) is a triumph of ingenuity, but that can't take away that it is not an approach you'd ever dream of creating now.  As it is at heart an analogue technology using radio frequency communication across multiple channels in a shared spectrum It has an inherent "fringe" of variable peak latencies, and a higher minimum latency than any modern optical fibre technology.  Things aren't quite so bad if you're on VM's very newest stretches of network, as these generally use FTTP and then analogue radio frequency coax through the wall (!).

Normal that's not a problem, but if things do go wrong with cable it is often the latency that suffers first.  

[adhsmith]

Thanks for confirming my suspicions, as mentioned it's tolerable, it was just not something I had considered when switching, otherwise it has all been good bar the outage this morning but it will certainly be something I will bear in mind when the contract is up for renewal.

Will the shift to DOCSIS 3.1 for Gig1 fibre rollout improve things or do the same inherent issues remain?

[Andrew-G]

The Hub 4 has somewhat better minimum latency than a Hub 3, but the change to DOCSIS 3.1 won't mean much further improvement.  Potentially you're already on D3.1 - if you look at the hub's status page and under Downstream you can see a DOCSIS 3.1 channel, then your segment may be enabled, but the Gig 1 product is usually only launched when the whole area has been upgraded.  On cable there's no relationship between bandwidth and latency, so Gig 1 wouldn't give any improvement to latency.  I do emphasise that when all works as it should, you shouldn't notice the fractionally worse latency of cable.

[adhsmith]

You would think its not noticeable but we work on the same remote machines when in the Bristol office and you can notice the difference between the office connection to the graphics design system at ~20ms where its super responsive compared to my home connection which was ~40ms, as you use a different speed connection you ultimately re-calibrate to whatever it is but initially you might get a menu/button miss etc.

Yup my hub  does indeed show a 3.1 channel but most are 3.0.

[Anonymous]

Okay let's stop with the fixation on DOCSIS, etc as it's not the issue.

The delay is due to Virgin Media / Liberty Global's peering and transit policies - how they interconnect with other networks.

Liberty really want to charge other networks for the privilege of sending data to their customers with the result that their connectivity to other networks isn't optimal.

No technical solution here just a policy one.

[Eeeps]

The problem is with the shared nature of the DOCSIS network at the local level, particularly on the upstream.

Primary Upstream Service Flow

SFID	305519
Max Traffic Rate	44000278
Max Traffic Burst	42600
Min Traffic Rate	0
Max Concatenated Burst	42600
Scheduling Type	BestEffort

Even if a particular modem has a very important packet to transmit it still has to potentially wait to get it's transmission slot.
Other shared networks do a better job (e.g. CAN bus in your car where priority of certain ECU data is important).

Unfortunately, the more recent PON networks have a similar local shared upstream structure so will eventually suffer problems not dissimilar to this

[Andrew-G]

@adhsmith Yup my hub  does indeed show a 3.1 channel but most are 3.0.

That's how DOCSIS 3.1 works under VM's implementation.  There's 31 downstream D3.0 channels, and one downstream D3.1 channel.  All channels work together to share the load, and at maximum bandwidth on a 1 Gig connection something around half the bandwidth comes through the D3.0 channels, and the other half comes through that single D3.1 channel.

If that sounds a tad odd, it is because DOCSIS came about as a way of offering data transmission crammed into a few bits of spare RF spectrum on analogue cable TV networks designed around downstream traffic, and so from the very start data was an afterthought.  Since then it has been incrementally improved, but each increment is built on a wobbly foundation, and everything has to be backwards compatible with older versions and older equipment.  What's being achieved now is incredible, but DOCSIS is a bit like the last days of CRT monitors and TVs - the outcome of the technology is superbly refined and capable of great things, but it is still a sunset technology that on close inspection is Grade 1A Heath Robinson, and some of the underlying problems (in particular the RF analogue local loop) will be exceptionally difficult to resolve.  The best effort scheduling that @Eeeps mentions might be addressed under the Low Latency DOCSIS arrangements provided for (but not mandated) in DOCSIS 4.0, but that would require new hubs that don't yet exist, and a full network upgrade which wouldn't even be started until 2026 because the D3.1 investments will have to be written down before VM go for another upgrade investment binge.  Even then, how well LLD works in practice remains to be seen - it isn't genuine low latency, but rather packet prioritisation.  If the majority of uses by then are latency sensitive, LLD is unlikely to be effective.

If you're noticing 10ms differences, then you'll have to hope that you don't get a bad day, because this is a good day on my VM (Hub 3) connection:

And this is a bad day:

I bet you're thinking "I wish I'd known this before committing for 18 months" !

[adhsmith]

To be honest I haven't really noticed the difference between the two home connections, not like when I go into the office, so I'm not going to obsess about it, it's fine, if I was a twitch fps gamer or something I'd be less happy, it was more a question of whether there was a button I could toggle or some VM side options that could be set to improve, having to VPN to places all over the world, I have to contend with whatever the internet throws up, so many things that can impact my overall latency.

A surprising aside the browsing experience, page responsiveness etc, has improved over Sky despite latency, so it's not all bad.

So long as it is stable and there's  no outage then it'll be fine but yup it's not as clean looking at BQMs

virgin

Sky

[Andrew-G]

Your VM BQM looks to be suffering some really bad spikes, and those are certainly bad enough to cause glitches in Teams or video calls.  Normally those can be tracked back to a noise fault and fixed.  Might be worth posting the hub status data for Downstream, Upstream and Network log here.