Virgin Media Discussion Thread

Aight, got me convinced. Doesn't take much persuading to get some new kit. :cry:

Do your research first (as always). Ideally build your own using a small low powered x86 box. For anything up to 1Gb, a PC Engines APU box running IPFire or bare Linux will do perfectly. Or you can get a cheap second hand SFF PC (Lenovo, HP, Dell) off eBay and install anything from OPNSense to IPFire to WRT to Untangle on it (or again, bare BSD or Linux). If you want something more off the shelf, look for a decently powered wired router (keep your APs separate) that supports something like WRT for the most flexibility and control.
 
So, we're hopefully moving house within the next few weeks and our options are either 30mbit BT (FTTP apparently underway, but not about to wait 18 months with crap internet) or up to 1gbit with Virgin... so a fairly clear choice even if Virgin network is full of latency. Expect the best option currently is signing up for a 350/500 offer and then a cheap o2 sim? My other half wants to leave Three due to crap signal so it works out for us to get a sim too.
 
So, we're hopefully moving house within the next few weeks and our options are either 30mbit BT (FTTP apparently underway, but not about to wait 18 months with crap internet) or up to 1gbit with Virgin... so a fairly clear choice even if Virgin network is full of latency. Expect the best option currently is signing up for a 350/500 offer and then a cheap o2 sim? My other half wants to leave Three due to crap signal so it works out for us to get a sim too.

VM latency isnt too bad, if you are in a good area. :)
 
Some people might not notice the latency issues depending on their usage but I can for gaming since switching from a stable FTTC connection with pretty much a perfectly flat TBB graph. Was worse on the HUB 3 but the likes of FIFA for example, I've had far more latency notifications popping up on screen than I did beforehand as well as speed up lag. I've had issues in other games such as Battlefield as well which weren't as apparent on my previous connection.

If you've been on VM for years then it is what it is and you'll be used to it. I think for those switching from a solid connection in terms of latency, jitter and no packet loss then they could notice some things.
 
To be fair most games me and the Mrs play are offline so the latency wouldn't be a massive issue. I play a bit of Battlefield but not heavily. As such I think having the improved download speeds are worth more than suffering with low speed FTTC until the FTTP rollout is completed from the local exchange.

Annoyingly, the exchange 0.6 miles away is already fully switched on to FTTP, yet our hopeful property is hooked up to an exchange near 3 miles away. Typical!
 
Some people might not notice the latency issues depending on their usage but I can for gaming since switching from a stable FTTC connection with pretty much a perfectly flat TBB graph. Was worse on the HUB 3 but the likes of FIFA for example, I've had far more latency notifications popping up on screen than I did beforehand as well as speed up lag. I've had issues in other games such as Battlefield as well which weren't as apparent on my previous connection.

If you've been on VM for years then it is what it is and you'll be used to it. I think for those switching from a solid connection in terms of latency, jitter and no packet loss then they could notice some things.

Its entirely area dependant. I've had virgin media in three areas of Cardiff. Two good and one terrible. The latest area, the one I used now (1Gbps) the connection is really good I can't think of any occasion where the latency, jitter or other has caused concern. Whilst I'd agree the VM infrastructure in some ways isn't as good as BT W/S its not night and day difference in a good area.
 
Its entirely area dependant. I've had virgin media in three areas of Cardiff. Two good and one terrible. The latest area, the one I used now (1Gbps) the connection is really good I can't think of any occasion where the latency, jitter or other has caused concern. Whilst I'd agree the VM infrastructure in some ways isn't as good as BT W/S its not night and day difference in a good area.

Not for me, as I said in a previous post I'm in a really good area and I still notice the difference.
 
Not for me, as I said in a previous post I'm in a really good area and I still notice the difference.

Then it seems unlikely you are in a really good area, as others - in seemingly better areas - don't have an issue.

I'm not sure how VM could ever compete against sub 7ms latency with next to no jitter in their current state.

You probably want to look into that, if I was paying for actual Fibre I wouldn't be happy with 7ms.

~$ ping bbc.co.uk
PING bbc.co.uk (151.101.0.81) 56(84) bytes of data.
64 bytes from 151.101.0.81 (151.101.0.81): icmp_seq=1 ttl=56 time=1.44 ms
64 bytes from 151.101.0.81 (151.101.0.81): icmp_seq=2 ttl=56 time=1.43 ms
64 bytes from 151.101.0.81 (151.101.0.81): icmp_seq=3 ttl=56 time=1.42 ms
64 bytes from 151.101.0.81 (151.101.0.81): icmp_seq=4 ttl=56 time=1.41 ms
64 bytes from 151.101.0.81 (151.101.0.81): icmp_seq=5 ttl=56 time=1.41 ms
64 bytes from 151.101.0.81 (151.101.0.81): icmp_seq=6 ttl=56 time=1.43 ms
64 bytes from 151.101.0.81 (151.101.0.81): icmp_seq=7 ttl=56 time=1.43 ms

^C

--- bbc.co.uk ping statistics ---
7 packets transmitted, 7 received, 0% packet loss, time 6008ms
rtt min/avg/max/mdev = 1.411/1.428/1.440/0.041 ms

** edit **
Even from well into mainland Europe I get this:

--- bbc.co.uk ping statistics ---
13 packets transmitted, 13 received, 0% packet loss, time 12010ms
rtt min/avg/max/mdev = 4.998/5.045/5.219/0.059 ms

Are your packets stopping for a coffee along the way?

** /edit **

VM's network is highly variable due to the way it was constructed, no set standards existed or were followed between many of the franchises and some franchises were built in quite literally the most inept and short sighted way possible, understandable given they were never intended to be used in the way they are today and the cost and time required to fix them was never going to be justified when they could barely make enough money to service the original build debt for the most part, so they stumbled along until they were consolidated and it became someone else's problem. Massive (relative to what had been done in the preceding decades) back end changes and investment took place after the NTL/TW merger, but it wasn't till Liberty Global got involved that they really pushed to move to a standardised approach across the network. Moving to RFoG short term will make things easier and should reduce faults longer term, the move to launch IPTV brings the potential to simplify massively going forward and things like cloud DVR become an option (may require some licensing renewals/tweaks/time), but simplifying CPE by removing local mechanical storage cuts faults/costs again, longer term getting rid of the RF side of things entirely and running pure IP is clearly the end goal.

It's natural to compare cable to fibre, the former is a fragmented network which has been coaxed (yea... I know) into doing a job that it was never designed to do and is gradually being re-built into something that has massive potential if properly invested in which LG seem to be willing to do. The latter has been built very recently using todays technology and subsidised like the original build by the tax payer with a clear goal and structure, though even with awareness that multi-gig services were going to be the norm, OR decided to install GPON's that they knew would need to be ripped out and replaced.
 
Then it seems unlikely you are in a really good area, as others - in seemingly better areas - don't have an issue.

My area is pretty much brand new and is RFoG with no faults. As above my graphs are in line with the better ones I've seen on VM without playing around with additional hardware and software configurations. The jitter and latency spikes are a well-known issue for gamers, it's no secret even for those in good areas. If you're playing a game and you get an 80-160ms ping spike during online gameplay, you're likely to notice it. A number of newer titles have latency notifications and I've matched some of these up with the spikes on my TBB graph.

I mean most gamers aren't even going to know what to look for if something dodgy happens during an online match, they'll just put it down to the game or whatever.
 
Last edited:
ledbat (bittorrents underlying protocol) aims for a delay target of anywhere between 25ms and 100ms. Bittorrent also switches to one new flow every 15 sec. It takes a while for each flow to ramp up but in "heavy bittorrenting" without fq_codel on the link you should have been seeing at least at least 25ms, more like 60ms over your baseline latency. You didn't show that - so I am assuming you weren't bittorrenting during that test? DOCSIS-pie has rolled out in several places which would essentially revert torrent to reno behavior + 16ms + spikes (because it is only a single queue aqm), which to me, seemed to be what your first pre-fq-codel graph showed.

fq_codel (and cake) are of course[1] better than pie, as flow queuing gets rid of the possibility of most spikes, in addition to having an AQM that tries for 5ms of queuing and usually gets it. Anyway, years ago we proved that any form of AQM or FQ defeated the e2e congestion controls in ledbat, and that it didn't matter.
https://hal.archives-ouvertes.fr/hal-01010472/

but I keep hoping to see a solid and non-theoretical result from the field.

[1] but I would say that, being one of the authors of fq_codel & cake that periodically pops up to see how well it is working for people.

(and it would be good to learn if VM had finally deployed docsis-pie or not)
 
Last edited by a moderator:
You probably want to look into that, if I was paying for actual Fibre I wouldn't be happy with 7ms.

~$ ping bbc.co.uk
PING bbc.co.uk (151.101.0.81) 56(84) bytes of data.
64 bytes from 151.101.0.81 (151.101.0.81): icmp_seq=1 ttl=56 time=1.44 ms
64 bytes from 151.101.0.81 (151.101.0.81): icmp_seq=2 ttl=56 time=1.43 ms
64 bytes from 151.101.0.81 (151.101.0.81): icmp_seq=3 ttl=56 time=1.42 ms
64 bytes from 151.101.0.81 (151.101.0.81): icmp_seq=4 ttl=56 time=1.41 ms
64 bytes from 151.101.0.81 (151.101.0.81): icmp_seq=5 ttl=56 time=1.41 ms
64 bytes from 151.101.0.81 (151.101.0.81): icmp_seq=6 ttl=56 time=1.43 ms
64 bytes from 151.101.0.81 (151.101.0.81): icmp_seq=7 ttl=56 time=1.43 ms

^C

--- bbc.co.uk ping statistics ---
7 packets transmitted, 7 received, 0% packet loss, time 6008ms
rtt min/avg/max/mdev = 1.411/1.428/1.440/0.041 ms

** edit **
Even from well into mainland Europe I get this:
Where are these from?
 
Yes, absolutely. You need to set up some kind of congestion control algorithm (as I said, fq_codel, cake, bbr) which will lose you a few megs on your up/downstream, but it's worth it. I can hammer my line now and still get almost my original full speed (about 935 megs down and 46 megs up), but my line stays extremely responsive for multiple users. Even when a torrent or other download/upload is going full whack it's almost perfect, especially compared to the mess that was there before I implemented the changes.

Yesterday I updated my Linux ISO collection (actually not a euphemism!) for the month, and had torrents running for almost 24h including seeding back. My BQM for yesterday shows the worst case for me now that I have fq_codel set up. Note that the singular red spike around lunch time was an intentional router reboot for updates:

az2Hq2H.png


too bad this will not help in areas with overutilization.
I'm seeding a torrent right now for testing and my upload fluctuate between 20 and 40mbps (I'm on gig1) with over 100 peers connected.
Actually seen it drop as low as 9mbps the other evening again that is on what they call "gigabit" connection.
Pathetic is all I can say....
 
Last edited:
I'm seeding a torrent right now for testing and my upload fluctuate between 20 and 40mbps (I'm on gig1) with over 100 peers connected.
Actually seen it drop as low as 9mbps the other evening again that is on what they call "gigabit" connection.
Pathetic is all I can say....
Uploading torrents is not going to be an accurate speed test!
 
Uploading torrents is not going to be an accurate speed test!
20-40mbps is the traffic flow in my MikroTik router.
With torrents I'm usually getting highest and most consistent download/upload speeds due to many connections.
When trying to upload a file to cloud servers or stream videos from my Plex/Emby servers it's even worse.
Yesterday night I could seed the same torrent at max speed.
Those upload speed drops happen during peak hours and on weekends for me so an indication of high network utilisation.
Outside of peak hours I'm getting decent speeds.

12280828900.png


Also had an engineer fix my power levels 2 days ago which increased my maximum upload speed by about 2Mbps but didn't fix speed drops during peak hours.
 
Last edited:
[1] but I would say that, being one of the authors of fq_codel & cake that periodically pops up to see how well it is working for people.

Ah you're *the* Dave Taht! :) It's a pleasure to be speaking with you, thanks for posting. A couple of things I'm not clear on, so it's hard to answer correctly:

in "heavy bittorrenting" without fq_codel on the link you should have been seeing at least at least 25ms, more like 60ms over your baseline latency. You didn't show that - so I am assuming you weren't bittorrenting during that test?

There wasn't a 'test' to be fair, this is just PC and gaming enthusiasts chatting about their Internet. There was no attempt at any kind of even the loosest of controlled conditions, I simply noticed that my BQM looked better after implementing fq_codel at the OpenBSD edge router, which is what we'd expect. My pre fq_codel graph certainly showed latency spikes to my eyes though; from a ~30ms baseline to over 120ms at points throughout the day where, I assume (as I can't remember exactly now) I was grabbing various distros and perhaps periodically seeding some back as they went. Perhaps I misunderstood you (which is probable).

As far as I'm aware, the BQM averages 100 seconds' worth pings to make each singular point on the graph[1]. If we take an average theoretical 1Gb distro (most are closer to 1.5GB to 2GB these days unfortunately), then under perfect conditions - which again, obviously don't exist - they'd be downloaded in 8 seconds flat at 1Gbps for a well seeded torrent. Even accounting for real world conditions, they don't take long at all. Not really enough to grossly affect a 100 second average measurement? If I understood your insinuation correctly, I think we're differing in our definition of 'heavy torrenting'. As I said, I was refreshing my (legitimate) Linux ISO collection, not grabbing 1TB of uncompressed BluRay rips continuously.

As I said I'm not actually sure what you're asking/saying, but if it makes any difference to your reply I only use *nix at home (hence already utilising some variant of *codel, bbr, etc at the desktop end, depending on whether it's FreeBSD/Linux), my traffic is almost invariably carried over UDP (WireGuard VPN) and I have uTP disabled in Transmission.

Either way, switching on fq_codel at the edge router end certainly made my BQM look better if I compare the week before and after enabling it[2]. It'd be interesting to chat more with you (the forum has a PM function) and if there's any testing you'd like to see on the Virgin Media line with and without various forms of congestion control, under better conditions, I'd be delighted to supply them for you. It'd be interesting to chat and learn something! Thanks again for taking the time to post and reply.

[1] https://www.thinkbroadband.com/faq/broadband-quality-monitor
[2] In pf.conf -
queue outq on em1 flows 1024 bandwidth 49M max 49M qlimit 1024 default
queue inq on em0 flows 1024 bandwidth 950M max 950M qlimit 1024 default
Edit: I've just downloaded your linked paper, btw, and I'm looking forward to reading it later, as soon as I have time.

Edit 2: Having had a moment to properly think about your reply, I think I’ve worked out the muddle. You’re Dave Taht, so when you say something’s not right I believe you. I didn’t stop to actually think that I may have been correct lol. You said the pre graph didn’t suggest torrent usage, but if you re-read my original posts, that was just a general “my VM latency is crap” image. The torrents were on the after graph, with my original point being that with fq_codel enabled even some torrents don’t make a mess of the ping graph any more. Before the graphs were randomly spiky and messy with any kind of download/upload activity. So, fq_codel working as intended. It’s a busy day and I’m fighting off an angry toddler and two young ones, posting from my phone, so apologies for any oversights, repetition or omissions. As I said I’d love to chat more.
 
Last edited:
Back
Top Bottom