It requires cooperation from the MPLS nodes (from man mtr):
-e, --mpls
Use this option to tell mtr to display information from ICMP extensions for MPLS (RFC 4950) that are encoded in the response packets.
not all MPLS nodes report this, but some do, how informative this is outside of "this passed via MPLS" without knowing the ISPs label msp I can not tell, but I find it interesting enough that I almost always use as part of my default mtr options mtr -ezb
I have tested all 3 IP's at my neighbor's... he has no packet loss... he is with another ISP
If you connect your PC direct to your ISP with no router in between, what does mtr say? Perhaps you have some kind of rate limit in icmp in your firewall rules causing the problem?
The test was done only with the ISP router connected directly to my pc... I replaced the ISP router with my router and I have no more loss... I assume it is damaged
Then talk to your isp and have it replaced... you still want their help in debugging the gaming issue.
They say they will check the line with smokeping to help me locate the source of the problem! Do you know what it is?
https://oss.oetiker.ch/smokeping/
I would doubt that this reveals anything useful in the end. They or you will maybe spot some latency spikes but then you still will not know "why".
Edit: or they use smoke ping as a placeholder name for just a generic ping test
smokeping is (as @_bernd helpfully linked) a tool that allows to use ICMP echo requests to monitor availability of end-points over time, with fancy graphs to display the distributions (which are gray scale and IMHO the "smoke" in smokeping). OpenWrt has its own built in version of that (alas without the smoke in the graphs) via the statistics/ping GUI, Also on thinkbroadband you can register freely for what they call Broadband Quality Monitor which is essentially a service by which they continuously ping your link from the outside and allow you to look at the last 60 or so days as fancy graphs like:
I set-up a dynamic DNS account for free with duckdns.org and configured my router to use that to publish its address to duckdns' DNS servers and configured the broadband quality monitor against the symbolic name and as you can see this works well (the red streak from the top at 3AM is from my ISP reconnecting my PPPoE link and giving me a new address, it takes a bit to do this dance and for thinkbroadband to pick up the new address but overall it is pretty nifty). I also use the address of thinkbroadband's pingbox as target of statistics/colletd's ping plug-in so I have results from both directions (only partially useful, one really would like bi-directional traceroutes).
Why does your latency go up to e.g. 60ms at times? Isn't that pretty significant on your connection (albeit entirely normal on mine to go up to 100ms on managed bufferbloat).
I have these running in the background because they are useful for debugging, but I do not use these as ground truth for encountered delay (for that I run a few collectd ping probes). So I think these veridically reflect some "load"/micro-congestion somewhere along the path, but not necessarily the true amount of latency-under-load, at least my own latency probes look considerably cleaner.
If you connect your PC direct to your ISP with no router in between, what does mtr say? Perhaps you have some kind of rate limit in icmp in your firewall rules causing the problem?
How can i Check this ?
This person had a problem similar to yours and found the cause of the problem:
You can also see this other thread:
Doesn't explain why he experiences the problem with PC, and PS4 and PS5... so an interesting finding, but I don't think it's the issue in this case.
Sorry for my late reply, I have very little time for myself at the moment.
Thanks for your help and research, I appreciate it!
We recently migrated from vdsl to FTTS, I get 520/130 bandwidth and I'm 60 m from the fiber junction. I notice that this latency has amplified the phenomenon of delay. I am convinced but without concrete evidence that the problem lies outside my home network, and certainly on the external network somewhere there is a bottleneck. Typically opening a web page with 70 mb of download was faster than with 500 mb... in summary the time needed to open a web page needs an extra second.
I have this monitor : MOBIUZ EX3210U
(4K, 144hz)
I don't know how the global network is designed, but I clearly have the feeling that one part of the world has no delay problems and the other half has delay on the gaming networks. So is it possible that all ISPs that cross a peering crossover (A) are smooth and all ISPs that cross a peering crossover (B) experience latency?
I understand that game developers don't necessarily have excellent netcode, but when you move your own hardware (pc, console, monitor and even the router) to another region or country everything is functional and fluid and when you return home everything is catastrophic, it's more a question of blaming the game developer(s), pc or console etc. in this situation!
It makes no sense because it works in another region or country!
If that's what's going on, then it should work through a VPN if you choose the VPN wisely (so that it avoids the congestion/delay link)
I think you did try using some vpn though right? did you try changing your point-of-presence / VPN server to various other locations?
My 2 cents:
This might interest you: I see this kind of behavior when I run a VPN over another VPN (mainly for testing purposes and tutorials). My upload goes to hell, but my download is still about 40mbps. So sending data becomes a real problem. This is a lot better when I switch VPN2 from UDP to TCP.
You could try a free/payed VPN with TCP and do a speed test.
I should indeed insist on the choice of geolocation according to the vpn chosen to validate that I have deviated from the congestion ... I tested Azirevpn, expressVPN , nolag vpn , Surfshark vpn ... it is true that there are several protocol as ikev2, tcp , udp, udp light .. it is true that I always choose the udp protocol and never test tcp. I will install again wireguard, the disadvantage is that I can not switch from a WG configuration to another in 1 clik as on Openvpn
Not doubting your data/experience, but that is against the (accepted and obvious) theory, as long as the network path to the remote VPN endpoint does not deprioritize or rate limit UDP, a VPN over UDP should be preferable. (Otherwise you risk running TCP over TCP and there the problem is if there is severe enough loss both the outer and inner TCP are going to try to resend missing packets which can cause quite a storm of needless retransmissions that still eats up capacity).
I agree, but I was merely trying to point out: a case can be made that if switching from UDP to TCP results in better performance that you could already be inside some tunnel. (because in normal circumstances UDP should have better performance)
Two things I would like to add:
and this is most likely another dead end.Just to be clear my setup uses VPN1=UDP VPN2=TCP.
And I think ProtonVPN has a good free tier with bare metal servers in japan, netherlands and usa.