I have already tested mobile data: 4G router, 5G, smartphone ... loss of packets, Ping varies from 35 to 300 ms. Concerning the screen the 3 have an input lag 1 ms, 144hz
I registered but during the configuration, my ISP is not recognized!
Yes set to 1492
For me it makes sense. Because this latency exists before arriving on my wan. All my games are impacted without exception... I receive the game stream too late, I play in the past, never in the present (realtime) it is a constant and permanent latency... at each renewal of public IP address everything becomes normal again but after 7 min everything becomes horrible again... As if after 7 min, an ISP firewall is activated or a mode switch at ISP or change of nodes, nat or no nat or change of segment ... according to random public IP provided by ISP the speeds change the Ping not much but enough to notice it and this is reflected in the responsiveness of the game. But I agree, the technicians follow a diagnostic protocol, when it exceeds their understanding everyone disappears, no one wants and knows how to correct or restore, so yes we are in the tolerance of the line quality etc. etc. ... for them internet works? Yes then that goes, we do not need to repair anything! It's like a motorcycle engine or car, if I put any spark plugs, the engine may not work long or poorly, bad performance ... technicians prefer to put the same spark plugs instead of putting the right model ...
So this is very interesting. I think you should find 5-6 random non-anycast addresses and ping all of them starting immediately after renewal of IP, and continue to ping them for 20 mins. Maybe using pingplotter or just log pings to a test file. See if there is a noticeable sudden change in latency.
You might use a few game servers, and then also use a few common websites, maybe news organizations in central Europe or govt websites or vendors like Amazon or whatever.
1 Like
So things like normal capacity tests (vulgo speedtest*) work as expected?
Where do you need to enter an ISP?
I just created a new dummy account and cobfigured a dummy monitor:
worked out of the box. During the creation there was a list of radio buttons, yes click any one you can leave the postcode field empty.
To show graphs (which will expire after ~3 months, so make a local copy for less ephemeral images) just copy and paste the link given as " Large Graph (800x350 px) - HTML Link"
*) Speed is distance change over time change, Mb is not a measure of distance, hence a "speedtest" does not measure speed. What it does measure is an estimate of the carrying capacity of the network path between client and server.
Assuming this is your IP (or rather your DDNS name) this looks as good as it gets, as if you did not actually use the network. I convince yourself that this actually does work, it can help to try to generate a lot of traffic for a few minutes (and disable SQM) in an attempt to drive up the queue and see latency spikes in this graph...
1 Like
While trying to fix this issue, I came across something interesting in regards to packets being out of order:
https://www.reddit.com/r/networking/comments/awr6t1/out_of_order_packets/
Now this was for another game, Fortnite, but it seems that it can be applicable all across the board. You have similar instances of inconsistency within the game. This part from the post stuck out to me, as it describes something that seems to be going on here as well:
Essentially this is packet loss, even though the game does not alert the user of the issue (packet loss indicator)
I'm not sure if it was discussed in this thread. If this is indeed the case, it seems like the ISP would have to look at this issue?
Will jumbo packets have any effect on out of order packets? Maybe that will help reduce the amount? can't say the same for users with pppoe connection
Jumbo packets typically do not work over the open internet, so I doubt that that would make a difference. If baby-jumbo frames should happen to make a difference it looks like a path MTU discovery failure...
If that's so then I'm not sure how to diagnose unordered packets case? Any idea?
Well you can take packet captures and try to see whether you can find some sequence numbers that allow you to figure out whether the observed sequence matches the expected sequence. This is "easy" for TCP but hard for UDP. Also if the re-ordering happens upstream of you for outgoing traffic you will never see it. HOWEVER games tend to send/receive in small batches based on the engined "ticks" so reordering also means that likely one packet from an earlier tick was also delayed long enough to interfere with the next ticks packets...
Reordering the packets of each individual tick should be something all games hopefully already perform, but I do not know how to check that.
1 Like
I notice on my captures by activating udp.time_delta and udp.time_relative, that the response time is different from 200 ms
Time since previous Time since first frame 0.012133000
0.237498000
0.000278000
0,000000000
0.004222000
0.301624000
0.011920000
0.286341000
0.000347000
0.252892000
0.012444000
3.003123000
Activating what and where? And where do you expect 200ms and for what reason? Sorry, to sound daft, but I have no real clue what the data is showing?
Excuse me it's with wireshark tools I added these 2 columns
OK, but are these incoming or outgoing packets, or both? And what temporal distance do you expect?
The thing is for TCP the sequence numbers allow easy checking of whether packets were reordered, but the UDP headers do not have such a field. So any application using UDP likely needs to use something like a sequence number or a timestamp to be able to sort UDP packets somehow, but since that is internal to the application the format is unlikely to be well documented. But remind me again, which game are you playing and having problems with mainly?
Hi, unfortunately I still haven't found a solution to this latency ... despite a game server ping of 7 ms, no packet loss and excellent jitter. I'm still experiencing 800 ms of latency in the game but I can't prove it! I asked my ISP operator, who lives in the same country as me, to do a traceroute on my public IP. We were surprised to find that the packets were going out of the country towards Switzerland (Frankfurt backbone) then Milan and finally back to Switzerland on my public IP. I find this type of traceroute unacceptable for 2 subscribers on the same ISP. Is this a problem because my game packets still have 7 ms on the same game server? What do you think is going on?
Well, how about you set-up a test in which you:
a) take a camera capable of slow motion recording (some android phones can record I believe 120 Hz video, and iphones probably laugh about puny 120Hz 
) and place it such that it can see both your hand on the relevant controller (stick and relevant button, or keyboard and mouse if on a computer) as well as your screen.
b) perform a control action that should result in immediate visual change (what exactly depends on your game) and record that
c) single frame step through the video and count how many frames are between the execution of the action (like button fully pressed, stick fully to one peripheral extreme position) and the expected results on the screen
d) convert the frame number into delay in milliseconds
That video and that number are pretty much the evidence you can take to the game company
Not sure what that means. As far as I can tell the gold standard for tracing is to get at least one traceroute each from each end-point to the other. That means you would need one trace from your computer to the game servers and one from the game servers to your computer... I would be amazed if the game company would play ball and do the reverse traceroute for you.
I honestly have too little information to make even a guess, sorry.
1 Like
Difficult to explain this with the translator ... my isp did a traceroute with my public IP as the destination ... we found a high Ping of 25 ms ... the logical result is 3 to 5 ms since we are on the same network! We also noted that the packets sent by isp to my destination transited Frankfurt (Germany) which represents an exit for the international (backbone) then transit by Italy (Milan) and finally return to Switzerland on my public IP... in summary: traceroute Switzerland, Germany, Italy then Switzerland.. the logic would like that the traceroute does not leave Switzerland. something escapes me because I do not find a logic with that. as I have clearly the feeling to play in differ and not in live I presume that the source of the problem comes from that! Does that seem plausible to you?