You are not logged in.
Pages: 1
I was checking this tool online and I noticed my latency is 207ms and packet loss 30% to simple. Not sure if im interpreting this results well but is this bad or normal? I can hardly play, had a good week last month and its back to being unplayable. I have 500mb fiber, Nvidia 1060, 16gb ram, new monitor 144hz with g-sync but I had better when I used a old latop from 2004...must be this net provider...
Last edited by Lecter (2021-03-10 02:45:55)
No tech expert??
Hi Lec!
Mostly the internet connection makes these results.
Wifi+router for me for example.I have to restart the whole "internet stuff" and 90% it works.
And ofc sometimes i forget to stop torrent upload.
Mille
It's also hard to make any kind of useful deduction from a snapshot in time like this. And sometimes, hard to make a useful deduction using an ICMP Echo (ping) at all.
For example, it appears this snapshot shows that there was a 207ms "outlying" measurement on hop 7, even though the average for that hop is 59ms. (i.e. Most were not 207ms.) Essentially "a single time", the measurement came back as 207ms.
So "is hop 7 prone to high ping?" We have no idea. All we know is that when measuring the round-trip to hop 7, "one time" it came back slow. It could have been hop 7 at fault, it could have been hop 6 at fault, or any prior hop. It would take more observations and data to say "is this measurement consistently at hop 7, or spread between multiple hops", which could mean the closest of those hops is the one being flaky.
But the 100% packet loss you're seeing at hop 3 and at bf1942.team-simple.org is "usually completely normal", and is just an indication that the device itself (router, server) or the network of the datacenter simply doesn't allow ICMP responses (ICMP Time To Live expired), or ICMP requests (ICMP Echo or "ping"). They simply don't allow the kind of traffic this measurement is attempting to employ. Nothing you can do about that for these existing tools, except try and make what conclusions you can about the intermediate devices that do respond to ICMP.
Meaning your in-game latency (which has to to with BF1942 game protocol, and nothing to do with ICMP Echo) may be fine, but attempting to PingPlot or traceroute shows failure. Although you can actually change what port some ping applications use (e.g. so it tries to hit the BF1942 14567 UDP port instead of ICMP), it usually doesn't let you give a payload that the server would actually respond to. Therefore even if using ping to hit the BF1942 game port, you would still have 100% packet loss, but for a different reason.
So it's almost like we need to create a BF1942-specific ping application, maybe hitting the smallest and easiest port 23000 status query the server can respond to quickly. So that the traffic we're using is something that reaches all the way to the game server, because it's a protocol that is / must be allowed for game usage. Whereas ICMP is not required and many times not allowed.
But the application would still employs IP TTL (Time To Live) when sending these game-specific ping attempts, to give a map of "how quickly did this communication attempt get failed from each hop." At least for whichever hops actually allow ICMP Time To Live Exceeded responses for packets that exhausted their TTL, which they still would not be required to actually do.
Thank you Trench and Millerke
Pages: 1