Menu
Reply
  • 10.39K
  • 303
  • 639
Forum Team
Forum Team
330 Views
Message 41 of 50
Flag for a moderator

Re: Latency higher than Virgin Media engineer tools shows

Hey najjun,

Thank you for keeping in touch Smiley Happy

Really sorry for the on-going connection problems you're experiencing. When I've tested your equipment this evening, I can see your SNR levels are high. Let's arrange for an engineer to call around to investigate further. I'll send you the appointment info via PM (purple envelope, top right).

Speak with you soon,

Take care.

Heather_J

Tech fan? Have you read our Digital life blog yet? Check it out


  • 18
  • 0
  • 0
najjun
On our wavelength
251 Views
Message 42 of 50
Flag for a moderator

Re: Latency higher than Virgin Media engineer tools shows

An Engineer was booked to come on Tuesday 22Nov17 between 12-4pm. 

NO ONE Turned up, let down badly again. Are they taking this seriously?

0 Kudos
Reply
  • 7.35K
  • 178
  • 424
Forum Team
Forum Team
208 Views
Message 43 of 50
Flag for a moderator

Re: Latency higher than Virgin Media engineer tools shows

Hi najjun, 

 

Thank you for keeping in touch, I am sorry to see yuo have continued to have have trouble with your connection. 

 

I have popped you a PM to discuss this further. 

 

Please keep an eye out for the Purple Envelope, top right hand corner. 

 

Speak to you soon. 

 

Emma


New around here? To find out more about the Community check out our Getting Started guide


0 Kudos
Reply
  • 3.14K
  • 36
  • 600
Ignition
Trouble shooter
187 Views
Message 44 of 50
Flag for a moderator

Re: Latency higher than Virgin Media engineer tools shows

Not sure OFSTED are going to be too helpful here.

VM's 'fastest' claim is based on download speeds, not on latency.

While I'm not a fan of the practice Ookla servers are on-net to eliminate some of the potential issues in testing to an external source.

If browsing responsiveness is an issue changing DNS servers may be appropriate.

If the complaint is that a single device on a single test reports a low figure on your line and an impossible one on a neighbour that's a problem.

If the complaint is that latency is higher on VM, well, that's how it is. They don't guarantee any kind of performance or appear to measure it. If we are talking averages VM's network is better than BT et al nationwide, however this is definitely not the case all the time.
0 Kudos
Reply
  • 3.14K
  • 36
  • 600
Ignition
Trouble shooter
184 Views
Message 45 of 50
Flag for a moderator

Re: Latency higher than Virgin Media engineer tools shows


griffin wrote:

VM use a different technology to BT and all the other ISPs using xDSL and work differently.

xDSL works by "line training" which adjusts the speed and the level of error correction to provide a stable speed. As this is based on the BER of the line, so speed is sacrificed to provide stabilty which will naturally give a lower ping than the best effort delivery of DOCSIS systems. So, comparing pings between VM and BT is pointless This is why BT speeds are dependant from the distance you are from the cabinet.

The question I would be asking is why Netfix is only showing 30Mbps whilst I am getting the full 100Mbps from other devices, what your neighbour is getting is irrelevant. I would assume he has been upgraded to 70Mbps or the obvious question would be how is he getting 74Mbps out of a 50Mbps connection.


Adjusting speeds based on BER would do nothing beyond to reduce BER and hence packet loss.

xDSL's rate adaption, etc, kicking in can only give a higher ping than VM's service due to application of interleaving and INP.

Fast path xDSL has a lower latency than cable because it is an unshared link between the customer and the DSLAM, they have the link exclusively to themselves and can transmit and be transmitted to on demand. Cable networks are shared at the local level so a customer's ping response may be delayed slightly in a queue behind other customers' packets, and as the return path uses ATDMA in order to actually transmit that ping request the customer must go through a request -> grant -> transmit cycle which adds latency in terms of carrying out the cycle and waiting for the grant to arrive and to be used.

The MAP that tells modems when they can transmit is sent every 2ms. As part of that MAP are some contended slots shared with other modems that another modem can try and send its request through on. If another modem sends at the same time that's some delay waiting for the next MAP to try and send another request for bandwidth. Worst case even without collisions this process can add 4ms to the latency. On top of this if channels are busy at that instant a modem may not receive a grant in the very next MAP, adding another 2ms for each MAP the modem is waiting for capacity to be freed up.

In VM's case their network, due to its size, can also take some interesting routes to destinations. They do not guarantee latency on our cable services for really good reasons.

  • 9.96K
  • 327
  • 866
legacy1
Hero
148 Views
Message 46 of 50
Flag for a moderator

Re: Latency higher than Virgin Media engineer tools shows

The latency issue for the hub 3 is downstream not upstream as soon as thats fixed things will be fine if its hardware not being powerful enough then we just have to wait and see for the hub 4.

0 Kudos
Reply
  • 18
  • 0
  • 0
najjun
On our wavelength
138 Views
Message 47 of 50
Flag for a moderator

Re: Latency higher than Virgin Media engineer tools shows

I think you have not read the global posts about the HUB3 with the faulty PUMA chip ... 

Even Virgin Media know that there is a 'known' problem ... see an extract from an email from VM to me ....
===============
'There is an open fault for slow speeds at peak times ref F005340964 and the current review date is 12/12/2017. Which may account for some latency during peak hours. 
The issue you are seeing may be related to this: http://community.virginmedia.com/t5/Gaming-Support/Hub-3-Compal-CH7465-LG-TG2492LG-and-CGNV4-Latency...
We have applied the test firmware to a number of hubs, and when trials are completed will carry out national updates.
==============

0 Kudos
Reply
  • 3.14K
  • 36
  • 600
Ignition
Trouble shooter
108 Views
Message 48 of 50
Flag for a moderator

Re: Latency higher than Virgin Media engineer tools shows

If that was addressed to me I'm aware of the Puma 6 issues, however those are nothing to do with manipulation of any test results. You seem to have gone from claiming that VM are manipulating test results because testers showed different latencies to the obvious - that there are issues with the Hub 3. These affect everything, they don't give VM's own on-net servers a free pass.

Hopefully they'll resolve the congestion issues sooner rather than later.

0 Kudos
Reply
  • 18
  • 0
  • 0
najjun
On our wavelength
84 Views
Message 49 of 50
Flag for a moderator

Re: Latency higher than Virgin Media engineer tools shows

Thu 30 Nov 17, Manager Mark Bennet came to my house. Very helpful, Very good customer service.

Replaced the Hub3 with a Hub2AC. He has also booked a RJ11 cable change to the cabinet.
But for the past few hours, getting timeouts every few seconds, Ping still high, see below
This is really effecting us.

4 bytes from 209.85.203.103: icmp_seq=21490 ttl=45 time=24.075 ms

64 bytes from 209.85.203.103: icmp_seq=21491 ttl=45 time=30.974 ms

64 bytes from 209.85.203.103: icmp_seq=21492 ttl=45 time=34.760 ms

64 bytes from 209.85.203.103: icmp_seq=21493 ttl=45 time=26.553 ms

64 bytes from 209.85.203.103: icmp_seq=21494 ttl=45 time=24.647 ms

64 bytes from 209.85.203.103: icmp_seq=21495 ttl=45 time=25.498 ms

Request timeout for icmp_seq 21496

64 bytes from 209.85.203.103: icmp_seq=21497 ttl=45 time=25.099 ms

64 bytes from 209.85.203.103: icmp_seq=21498 ttl=45 time=23.742 ms

64 bytes from 209.85.203.103: icmp_seq=21499 ttl=45 time=23.751 ms

64 bytes from 209.85.203.103: icmp_seq=21500 ttl=45 time=24.827 ms

64 bytes from 209.85.203.103: icmp_seq=21501 ttl=45 time=60.777 ms

64 bytes from 209.85.203.103: icmp_seq=21502 ttl=45 time=28.876 ms

64 bytes from 209.85.203.103: icmp_seq=21503 ttl=45 time=33.761 ms

64 bytes from 209.85.203.103: icmp_seq=21504 ttl=45 time=36.012 ms

64 bytes from 209.85.203.103: icmp_seq=21505 ttl=45 time=31.323 ms

Request timeout for icmp_seq 21506

64 bytes from 209.85.203.103: icmp_seq=21507 ttl=45 time=79.061 ms

64 bytes from 209.85.203.103: icmp_seq=21508 ttl=45 time=51.037 ms

64 bytes from 209.85.203.103: icmp_seq=21509 ttl=45 time=27.678 ms

64 bytes from 209.85.203.103: icmp_seq=21510 ttl=45 time=22.696 ms

64 bytes from 209.85.203.103: icmp_seq=21511 ttl=45 time=28.574 ms

64 bytes from 209.85.203.103: icmp_seq=21512 ttl=45 time=23.870 ms

64 bytes from 209.85.203.103: icmp_seq=21513 ttl=45 time=30.590 ms

64 bytes from 209.85.203.103: icmp_seq=21514 ttl=45 time=24.883 ms

64 bytes from 209.85.203.103: icmp_seq=21515 ttl=45 time=32.730 ms

64 bytes from 209.85.203.103: icmp_seq=21516 ttl=45 time=24.674 ms

64 bytes from 209.85.203.103: icmp_seq=21517 ttl=45 time=25.377 ms

Request timeout for icmp_seq 21518

64 bytes from 209.85.203.103: icmp_seq=21519 ttl=45 time=25.209 ms

64 bytes from 209.85.203.103: icmp_seq=21520 ttl=45 time=24.542 ms

64 bytes from 209.85.203.103: icmp_seq=21521 ttl=45 time=28.024 ms

64 bytes from 209.85.203.103: icmp_seq=21522 ttl=45 time=23.953 ms

64 bytes from 209.85.203.103: icmp_seq=21523 ttl=45 time=23.839 ms

64 bytes from 209.85.203.103: icmp_seq=21524 ttl=45 time=28.381 ms

64 bytes from 209.85.203.103: icmp_seq=21525 ttl=45 time=25.558 ms

64 bytes from 209.85.203.103: icmp_seq=21526 ttl=45 time=39.716 ms

64 bytes from 209.85.203.103: icmp_seq=21527 ttl=45 time=25.233 ms

64 bytes from 209.85.203.103: icmp_seq=21528 ttl=45 time=32.597 ms

64 bytes from 209.85.203.103: icmp_seq=21529 ttl=45 time=25.905 ms

64 bytes from 209.85.203.103: icmp_seq=21530 ttl=45 time=26.711 ms

64 bytes from 209.85.203.103: icmp_seq=21531 ttl=45 time=55.518 ms

64 bytes from 209.85.203.103: icmp_seq=21532 ttl=45 time=36.777 ms

Request timeout for icmp_seq 21533

Request timeout for icmp_seq 21534

64 bytes from 209.85.203.103: icmp_seq=21535 ttl=45 time=34.088 ms

64 bytes from 209.85.203.103: icmp_seq=21536 ttl=45 time=28.438 ms

^C

--- www.google.com ping statistics ---

21537 packets transmitted, 21052 packets received, 2.3% packet loss

round-trip min/avg/max/stddev = 17.676/32.463/1176.548/29.593 ms

 

0 Kudos
Reply
  • 18
  • 0
  • 0
najjun
On our wavelength
12 Views
Message 50 of 50
Flag for a moderator

Re: Latency higher than Virgin Media engineer tools shows

For the last 3 hours, the quality of browsing or streaming has gone down , browsing pages hangs constantly every 10 seconds or so, streaming video is pixellating, I even saw issues when streaming from my local server so this maybe pointing at the modem

0 Kudos
Reply