I've had a lot of problems with online gaming in Battlefield 1. I've called Tech Support 7 or 8 times and had numerous power level tweaks, reset the router, identified some SNR issues etc etc. I had an engineer out on Monday who replace some wiring in the cabinet and replaced my SH2 with a SH3. It hasn't helped. I called again yesterday and was put through to 2nd level support who thought the issue might be with EA servers or the route to them. The tracert shows fine sometimes and others it's high. He didn't think it was to do with Virgin media network though. I've since run several tracerts and found high ping levels in the first 2-3 hops too so I'm not convinced it's beyond Virgin network.
Called again this morning. Was put through to Gadget Support (really?) who transferred me back. While explaining my problem yet again to tech support they transferred me again to Gadget Support as I was telling him my issue. I was pleasant and polite.
By having your hub 2 replaced they have now actually made your problem worse. The CPU fault in the hub 3 itself causes latency and jitter problems in excess of 200ms, so add that to your previous fault and it really isn’t ideal at all.
Just as an observation by looking at your graph do you have anything hammering your upload? It looks like you may be saturating your upstream and this in itself causes latency problems, anything like p2p or game video broadcasting? Twitch or similar is what I mean.
First of all your tracerts are fine and will not explain any gaming lag, however, tracerts only show you what is happening in a split second of time and are only useful in showing where the congestion is happening. I have included an explaination on how tracerts work below.
Are you playing with a devices connected to the hub by ethernet cable or wirelessly?
The BQM is interesting. The section before 12pm shows occasional lag spikes which I think can be attributed to the Puma 6 issue with the Hub 3.
The section between 12 and 4pm looks like the connection has been hammered as cje85 suspects as it has clearly defined edges, might be you or a neighbour, or there was a local shortlived SNR fault.
As a sanity check, it would be worth posting the hub's power levels and network logs.
The section after 4pm shows the lag spikes getting more frequent and an increase of average latency. This can be espected during evening peak when your local node will be busier and maybe congested enough to disrupt online gaming somewhat, your pingplotter graph is going into the yellow and red suggesting the ping is high enough to cause lag.it maybe worth doub;e clicking on a area of the time graph where the ping is going into the yellow to see what affect it has on the route trace.
A VM Forum Team member should be able to advise you on the traffic levels on your local node when they pick up the thread.
A Source computer will send a series of ICMP packets to a Target server with a ICMP Timeout Echo Request and a Time to Live Value.
The first series of ICMP packets will be sent with a TTL value of 1.
The first server on the route will decrease the TTL value by 1.
So, once the first series of ICMP packets reach the first server the TTL balue is reduced by 1 to 0 and the packets time out. The server at hop 1 is a polite server and responds to the source with a ICMP Timeout echo containing a timestamp when the packets timed out. From the time the source sent the packets and the timestamp contained in the Timeout Echo the Source can work out the Round Time Trip.
The Source now sends a second set of ICMP packets which reach the server at Hop 1 which reduces the TTL value by 1 and sends the packets on their merry way towards the Target.
The Server at Hop 2 reduces the TTL value by 1 so the new TTL value is 0 and the packet times out. This time though, the Server is busy and as ICMP packets are low priority as they carry no data, the Server at Hop 2 takes it's time replying to the Timeout Echo Request as it is doing more important things like making the coffee.
Once the Source has recieved the Timeout Echo from the Server at Hop 2 the Source sends another series of ICMP packets increasing the TTL value to 3. The ICMP packets make their way to the Target Server through the Servers at Hop 1 and Hop 2 which reduce the TTL by 1 to the Server at Hop 3 which reduces the TTL value by 1so the TTL value is 0 again and the packets time out. This time the Server is configured to ignore ICMP Timeout Echo Requests and does not reply to the Source. The Source does not receive a reply and times out showing a star for that Hop.
The Source now sends another series of ICMP packets to the target with a TTL value of 4. This time the Server at Hop 4 replies to the ICMP Timeout Echo Request in a timely manner.
The Source will carry on sending ICMP packets to the Target Server with increasing TTL values until the Target Server is reached (or the Max Hop Value)
It is the last hop that is important.
For example, taking the tracerts you have highlighted in red you noticed a high ping at Hop 3, ok that might be a problem, but on further inspection of the route the end hop has a much lower ping and do all other susequent hops along the route. So, this indicates the Server at Hop 3 is configured to treat ICMP Timeout Echo requests as low priority.
In your last post you again noticed a high ping at Hop 3. This time though all susequent pings are higher and more importantly the last hop is as well. This time you have diagnosed the tracert perfectly. However, I do not think the ping time at the end of the trace is high enough to cause any problems with online gaming.
Thanks for your post Griffin. Just a few points below.
I'm playing via PC and Ethernet 1m from the superhub.
The BQM was while I had the SH2 rather than the replaced SH3.
The problem is the same on SH2 & SH3.
I've played Battlefield 1 since release in October 2016 at the same times of day on the same PC and it's been absolutely fine. Whatever's happened has happened in the past fortnight. I only use the PC for this and nothing else and haven't installed anything new on it or changed it.
The distance from the hub has no bearing when connected to the hub by ethernet cable, you are only governed by the length of ethernet cable connecting the PC to the hub.
When did you get the Hub 3?
Have you had a good gaming experience with the Hub 3 all times of day in the past?
A Ping plot during the day would be handy for comparison against the pingpot during the evening.
It will stil be useful to post the power levels and logs to see if there is an obvious circuit impairment.
As said previously a VM Forum team membercan advise on the level of traffic on your local node. it could be an increase in local traffic componding the Puma 6 to a level where the ping spikes cause lag.
I got the SH3 last Wednesday (6 days ago) following the engineer coming to see if he could find a problem. So I've not had a good gaming experience with the SH3 at all or with the SH2 in the past fortnight.
I'll look at the power levels tonight and post them.