Menu
Reply
Highlighted
  • 10
  • 1
  • 2
MaCc1991
Tuning in
810 Views
Message 1 of 14
Flag for a moderator

Packet loss/Lag spikes

When gaming I'm seeing delay in inputs which makes me assume high ping but, ping shows as stableish on a BQM.a88d74b9f4987c5f53485d90cd0e6687a78dcaf3-19-12-2018.png

 Now my main issue is with playing FIFA, no matter what troubleshooting I do nothing changes, it is still very delayed when it comes to passing, shooting, ball control or any movements. Now I know people on the same service with virgin who don't have any issue so I can isolate the problem to either my hardware, line or area.

This is a UOtrace to FUT servers.IMG_20181222_031135.jpg

 As you can see I have 100% loss one several hops on VM network.

Now just to see if it's an issue to EA servers I also tested Google.IMG_20181222_031118.jpg

 Same story, 100% loss on many hops, most concerning being the loss between my modem and what I can assume is the cabinet in the street, since the next hop is the exchange in uddingston.

 

When I call in about this any mention of packet loss or ping and the agents do not want to discuss it, they just say restart the router and "do a speed test" and as a former employee of Virgin, I know fine well from training that they know this isn't even remotely what to do.

 

I'm basically at my wits end, I have an engineer visit (my 5th since september) and I'm hoping they finally fix it, but in the mean time any advice on what to tell the engineer to look for in terms of fixing this?

 

 

 

 

 

 

 

 

0 Kudos
Reply
  • 10
  • 1
  • 2
MaCc1991
Tuning in
809 Views
Message 2 of 14
Flag for a moderator

Re: Packet loss/Lag spikes

Oh and before anyone asks, I use wired for gaming, I used wired for all tests i ran too. Ive opened ports, assigned static IPs etc.

  • 347
  • 33
  • 98
DreamOfCheese
Superfast
803 Views
Message 3 of 14
Flag for a moderator

Re: Packet loss/Lag spikes

The images haven't been approved yet so I can't see them, but 100% loss on traceroutes is a fairly common occurance, not all routers along the path are configured to respond to ICMP requests. If it genuinely was 100% loss the packets wouldn't go any further after that point.
0 Kudos
Reply
  • 10
  • 1
  • 2
MaCc1991
Tuning in
708 Views
Message 4 of 14
Flag for a moderator

Re: Packet loss/Lag spikes

Images are now approved. Issue still persisting and I now understand the 100% loss hops and my connection looks perfectly fine in those traceroutes but I have ran one for lengthy periods of time to see if it spikes and it seems to spike up and down from 200 at times on its way through to the servers. I've had another engineer visit and everything is perfectly fine at my home so the issue is internally with VM somewhere.

0 Kudos
Reply
  • 347
  • 33
  • 98
DreamOfCheese
Superfast
704 Views
Message 5 of 14
Flag for a moderator

Re: Packet loss/Lag spikes

The traceroutes in the images shown nothing out of the ordinary, some hops that aren't responding to ICMP because they're configured not to, the ones that are replying have no loss and a fairly stable best/worst with the endpoint being stable to within 1ms.

The ping graph also looks fine for the average/maximum latency, the small drips of red at the top shouldn't be there but they're not frequent enough to be causing what you're mentioning.

Using traceroute to monitor ping is not an optimal solution as routers along the way prioritise the routing of traffic over responding to ICMP echo requests so will occasionally spike up in latency even if the hop is perfectly healthy. Just pinging the server normally and looking for spikes is how you'd check for jitter as any issue along the path will still show itself.
0 Kudos
Reply
  • 10
  • 1
  • 2
MaCc1991
Tuning in
699 Views
Message 6 of 14
Flag for a moderator

Re: Packet loss/Lag spikes

Heres a CMD ping to the server in question. (I'll leave out the separate ping as It will just be a lot of text)

Pinging gosprodfeapp7031.ea.com [159.153.28.33] with 32 bytes of data:
Reply from 159.153.28.33: bytes=32 time=29ms TTL=52
Reply from 159.153.28.33: bytes=32 time=32ms TTL=52
Reply from 159.153.28.33: bytes=32 time=25ms TTL=52
Reply from 159.153.28.33: bytes=32 time=25ms TTL=52
Reply from 159.153.28.33: bytes=32 time=34ms TTL=52
Reply from 159.153.28.33: bytes=32 time=26ms TTL=52
Reply from 159.153.28.33: bytes=32 time=27ms TTL=52
Reply from 159.153.28.33: bytes=32 time=43ms TTL=52
Reply from 159.153.28.33: bytes=32 time=26ms TTL=52
Reply from 159.153.28.33: bytes=32 time=26ms TTL=52
Reply from 159.153.28.33: bytes=32 time=28ms TTL=52
Reply from 159.153.28.33: bytes=32 time=28ms TTL=52
Reply from 159.153.28.33: bytes=32 time=43ms TTL=52
Reply from 159.153.28.33: bytes=32 time=30ms TTL=52
Reply from 159.153.28.33: bytes=32 time=26ms TTL=52
Reply from 159.153.28.33: bytes=32 time=27ms TTL=52
Reply from 159.153.28.33: bytes=32 time=43ms TTL=52
Reply from 159.153.28.33: bytes=32 time=45ms TTL=52
Reply from 159.153.28.33: bytes=32 time=27ms TTL=52
Reply from 159.153.28.33: bytes=32 time=26ms TTL=52
Reply from 159.153.28.33: bytes=32 time=45ms TTL=52
Reply from 159.153.28.33: bytes=32 time=25ms TTL=52
Reply from 159.153.28.33: bytes=32 time=44ms TTL=52
Reply from 159.153.28.33: bytes=32 time=26ms TTL=52
Reply from 159.153.28.33: bytes=32 time=27ms TTL=52
Reply from 159.153.28.33: bytes=32 time=29ms TTL=52
Reply from 159.153.28.33: bytes=32 time=25ms TTL=52
Reply from 159.153.28.33: bytes=32 time=26ms TTL=52
Reply from 159.153.28.33: bytes=32 time=44ms TTL=52
Reply from 159.153.28.33: bytes=32 time=27ms TTL=52
Reply from 159.153.28.33: bytes=32 time=26ms TTL=52
Reply from 159.153.28.33: bytes=32 time=30ms TTL=52
Reply from 159.153.28.33: bytes=32 time=30ms TTL=52
Reply from 159.153.28.33: bytes=32 time=43ms TTL=52
Reply from 159.153.28.33: bytes=32 time=25ms TTL=52
Reply from 159.153.28.33: bytes=32 time=26ms TTL=52
Reply from 159.153.28.33: bytes=32 time=27ms TTL=52
Reply from 159.153.28.33: bytes=32 time=45ms TTL=52
Reply from 159.153.28.33: bytes=32 time=25ms TTL=52
Reply from 159.153.28.33: bytes=32 time=44ms TTL=52
Reply from 159.153.28.33: bytes=32 time=46ms TTL=52
Reply from 159.153.28.33: bytes=32 time=46ms TTL=52
Reply from 159.153.28.33: bytes=32 time=35ms TTL=52
Reply from 159.153.28.33: bytes=32 time=30ms TTL=52
Reply from 159.153.28.33: bytes=32 time=50ms TTL=52
Reply from 159.153.28.33: bytes=32 time=54ms TTL=52
Reply from 159.153.28.33: bytes=32 time=50ms TTL=52
Reply from 159.153.28.33: bytes=32 time=26ms TTL=52
Reply from 159.153.28.33: bytes=32 time=98ms TTL=52
Reply from 159.153.28.33: bytes=32 time=26ms TTL=52
Ping statistics for 159.153.28.33:
    Packets: Sent = 50, Received = 50, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 25ms, Maximum = 98ms, Average = 34ms
 
 
There is no loss so thats not the issue it. My ping mostly seems stable so I am honestly at this point so confused as to what is causing this. I have been through every step of troubleshooting with EA about this, they say it's on my end as they've took every step to help me that they can.
 
My friend plays the game too and doesn't have this issue, he connects to the same local data centre I do on hop 3 of traceroutes as we stay somewhat in the same area, so im now left to think it's an issue between me and that data centre. I've had an engineer out to check my equipment and he says there's no issue, I have tried a brand new ps4, I play on a 3ms monitor and a wired controller so it's not input lag from my screen or controller. Also to add the "delay" is not my imagination as one of my friend who has tried to help me resolve this thinks as networking tests I do show no issues. 
 
When I play fortnite or cod on the same ps4 there is no issue whatsoever. So i'm extremely confused as to what's happening.
0 Kudos
Reply
  • 347
  • 33
  • 98
DreamOfCheese
Superfast
697 Views
Message 7 of 14
Flag for a moderator

Re: Packet loss/Lag spikes

Was that ping done from a wired device, and was anyone doing anything bandwidth intensive at the time? Netflix, etc.
Whilst there isn't any loss and the jitter isn't enormous, it is still not very stable and FIFA may simply be very sensitive to this. I've just done a test to the same IP from my connection for comparison.

 

Spoiler

64 bytes from 159.153.28.33: icmp_req=1 ttl=55 time=22.1 ms

64 bytes from 159.153.28.33: icmp_req=2 ttl=55 time=21.6 ms

64 bytes from 159.153.28.33: icmp_req=3 ttl=55 time=22.3 ms

64 bytes from 159.153.28.33: icmp_req=4 ttl=55 time=22.0 ms

64 bytes from 159.153.28.33: icmp_req=5 ttl=55 time=21.8 ms

64 bytes from 159.153.28.33: icmp_req=6 ttl=55 time=22.2 ms

64 bytes from 159.153.28.33: icmp_req=7 ttl=55 time=22.0 ms

64 bytes from 159.153.28.33: icmp_req=8 ttl=55 time=22.7 ms

64 bytes from 159.153.28.33: icmp_req=9 ttl=55 time=21.7 ms

64 bytes from 159.153.28.33: icmp_req=10 ttl=55 time=21.6 ms

64 bytes from 159.153.28.33: icmp_req=11 ttl=55 time=22.0 ms

64 bytes from 159.153.28.33: icmp_req=12 ttl=55 time=21.4 ms

64 bytes from 159.153.28.33: icmp_req=13 ttl=55 time=21.1 ms

64 bytes from 159.153.28.33: icmp_req=14 ttl=55 time=21.2 ms

64 bytes from 159.153.28.33: icmp_req=15 ttl=55 time=21.7 ms

64 bytes from 159.153.28.33: icmp_req=16 ttl=55 time=21.4 ms

64 bytes from 159.153.28.33: icmp_req=17 ttl=55 time=20.9 ms

64 bytes from 159.153.28.33: icmp_req=18 ttl=55 time=22.8 ms

64 bytes from 159.153.28.33: icmp_req=19 ttl=55 time=21.7 ms

64 bytes from 159.153.28.33: icmp_req=20 ttl=55 time=22.1 ms

64 bytes from 159.153.28.33: icmp_req=21 ttl=55 time=22.5 ms

64 bytes from 159.153.28.33: icmp_req=22 ttl=55 time=21.2 ms

64 bytes from 159.153.28.33: icmp_req=23 ttl=55 time=21.6 ms

64 bytes from 159.153.28.33: icmp_req=24 ttl=55 time=22.5 ms

64 bytes from 159.153.28.33: icmp_req=25 ttl=55 time=22.0 ms

64 bytes from 159.153.28.33: icmp_req=26 ttl=55 time=21.6 ms

64 bytes from 159.153.28.33: icmp_req=27 ttl=55 time=21.0 ms

64 bytes from 159.153.28.33: icmp_req=28 ttl=55 time=21.4 ms

64 bytes from 159.153.28.33: icmp_req=29 ttl=55 time=21.5 ms

 

 

0 Kudos
Reply
  • 10
  • 1
  • 2
MaCc1991
Tuning in
688 Views
Message 8 of 14
Flag for a moderator

Re: Packet loss/Lag spikes

Everyone is asleep in my house, the only other thing thats actually turned on that uses the internet other than this laptop is my V6 box and im only watching UFC on it, not doing anything that should use bandwith. Test was done wired, I use wired for PS4 & PC. It's only phones/V6/Echo that use the wifi.

Is there even anything I can do about this? or will it be a case of "it's your area" or me complaining to VM endlessly like I currently am until the end of time?

 

  • 347
  • 33
  • 98
DreamOfCheese
Superfast
685 Views
Message 9 of 14
Flag for a moderator

Re: Packet loss/Lag spikes

Well based on the average latency in your ping graph there doesn't seem to be anything that should be causing it to be as jittery as it is, which should mean that you can rule it out as being power level issues or something specific to your connection.

If you ping a different IP does it show the same level of jitter? Perhaps try pinging virginmedia.com so that it localises to within the VM network.
0 Kudos
Reply
  • 10
  • 1
  • 2
MaCc1991
Tuning in
684 Views
Message 10 of 14
Flag for a moderator

Re: Packet loss/Lag spikes

Yeah it jumps up when pinging virginmedia.com

 

Spoiler
Pinging virginmedia.com [213.105.9.24] with 32 bytes of data:
Reply from 213.105.9.24: bytes=32 time=18ms TTL=247
Reply from 213.105.9.24: bytes=32 time=37ms TTL=247
Reply from 213.105.9.24: bytes=32 time=17ms TTL=247
Reply from 213.105.9.24: bytes=32 time=15ms TTL=247
Reply from 213.105.9.24: bytes=32 time=34ms TTL=247
Reply from 213.105.9.24: bytes=32 time=14ms TTL=247
Reply from 213.105.9.24: bytes=32 time=15ms TTL=247
Reply from 213.105.9.24: bytes=32 time=15ms TTL=247
Reply from 213.105.9.24: bytes=32 time=15ms TTL=247
Reply from 213.105.9.24: bytes=32 time=16ms TTL=247
Reply from 213.105.9.24: bytes=32 time=33ms TTL=247
Reply from 213.105.9.24: bytes=32 time=33ms TTL=247
Reply from 213.105.9.24: bytes=32 time=33ms TTL=247
Reply from 213.105.9.24: bytes=32 time=32ms TTL=247
Reply from 213.105.9.24: bytes=32 time=33ms TTL=247
Reply from 213.105.9.24: bytes=32 time=33ms TTL=247
Reply from 213.105.9.24: bytes=32 time=34ms TTL=247
Reply from 213.105.9.24: bytes=32 time=33ms TTL=247
Reply from 213.105.9.24: bytes=32 time=33ms TTL=247
Reply from 213.105.9.24: bytes=32 time=33ms TTL=247
Ping statistics for 213.105.9.24:
    Packets: Sent = 20, Received = 20, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 14ms, Maximum = 37ms, Average = 26ms
0 Kudos
Reply