Ping time testing

rpm

Admin
Staff member
Joined
Jul 22, 2003
Messages
66,806
Reaction score
5,057
Location
Johannesburg
Hi there

I need some assistance regarding game server ping times. Is it possible to test the ping times of gaming servers without the need to ping from the application itself? One can obviously use standard pings, but these values are simply HTTP-TCP pings which is not representative of the true ping times when playing online.

Regards,

RPM
[email protected]
 
To the best of my knowledge the "standard ping" or a ping generated by the "ping application" is in fact using the IP/ICMP protocols, ICMP type 8 (ECHO REQUEST) to be exact. If the game is using a ping to report the latency it is most probably using IP/ICMP to do so since that is what a PING is. The values given by the game and the "ping application" should be identical, provided the ICMP data size in the games netcode is less than the connections actual bandwidth capacity.

I have tested to confirm this theory :) With my ISDN line I issue a ping through the command line to wanderhome.starwarsgalaxies.com and it returns a 350ms reply. Whilst in game the bandwidth monitor reports a 351ms (average) reply.

I think it is safe to say that the "ping application" will provide accurate results. I could be wrong though :)
 
Hi Scandium

Thanks for the information.

I think your argument is correct for standard web environment, but with Telkom’s ADSL service port prioritizations (traffic shaping) is applied which means that certain traffic (HTTP, FTP, SMTP) enjoys a higher priority. This is a commonly uses QoS mechanism to favor certain applications. Since the gaming applications will usually make use of ports other then the ones mentioned the traffic will have delays which causes longer ping times. I have tested this and the ping times can differ with a factor of a 100 during busy times. I would therefore like a way to actually test ping time for port 500 traffic to a certain gaming server, for example. I don’t know if I am on the right track here and maybe somebody can clear up this matter.

Regards,

RPM
[email protected]
 
<blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">quote:<hr height="1" noshade id="quote"><i>Originally posted by rpm</i>
I think your argument is correct for standard web environment, but with Telkom’s ADSL service port prioritizations (traffic shaping) is applied which means that certain traffic (HTTP, FTP, SMTP) enjoys a higher priority.
<hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">

I suspect that port prioritization has been decreased to some extent. For example Kazaa used to suffer badly from the prioritization, but now seems to work pretty well.

Anyone else with the same findings?
 
Yeah,If I find a file with many users I can easily get a D/L speed of 52KB/S.[:)]and thats anytime of the day aswell.
 
Hi rpm
I use the "all seeing eye" application to check the ping before choosing a server. give it a bash. however, i sometimes find the ping higher when playing.
not sure where i got it. search on google or tucows.

Telkom - South Africa's Handbrake to progress.
 
Hi RPM,

I forgot about that port prioritization on the ADSL, that may very well effect the ping times and of course their routing might not be up to scratch (I have some small idea that the ADSL network is very messy at this stage). That would most probably deliver inaccurate ping times also probably what makes the pings so unstable.

In terms of the prioritization being decreased, I think they made a mistake. I tried emule a few months back and it would max out at about 0.6kbps, mid January I tried again and I was hitting 52kbps no problem, about two weeks after it was back down again. Im not too sure if this is the case but I can't imagine Telkom actually wanting to please their customers.

RPM, I will look into the traffic shaping/prioritization and see if it effects ICMP packets, will let you know if I find something.
 
Best application for measuring pings is pingplotter http://www.pingplotter.com/ . You can leave it running for days on end to pick up trends to an address, where problems are in the trace-route etc. Been using it for years as I do most of my gaming overseas, and it's been an invaluable tool for me.
 
I am not sure as to how you can exactly measure the impact of bandwidth shaping. Ping doesn't cut it since it only reports latency and not available bandwidth, and its packet loss indication is not very precise since it doesn't test specific ports. Below is my experience with regard to the Telkoms bandwidth shaping, hope it gives you some ideas.

Personally right now the ping times to international servers (I am playing Everquest again) aren’t too bad on ADSL. The problem however is packet loss, during December and January there was almost 0 percent packet loss, as of late January to now I keep getting between 10-40 percent packet loss, making online international games almost impossible to play.

This whole bandwidth shaping is pure BS, Kazaa, eDonkey etc. run just fine, the only apps that seem to suffer are legitimate applications like VPNs and online games. As of today I am canceling my ADSL and going back to ISDN for this exact reason. Why someone on ISDN shouldn't have bandwidth shaping yet ADSL users have to suffer through it is beyond me. Telkom still thinks that shaping blocks P2P or limits its usefulness, when any half tech savvy computer user knows how to bypass their shaping by reconfiguring the ports.

Ports also seem to be capped at 4KB/s, not very noticable when using P2P application since you are downloading from a variety of sources, it does however make a huge difference to VPNs and online gaming.
 
In the case of ADSL DarkSkies is right, a simple ICMP 'ping' would not be a very acurate refflection. It is however the only real way to test an end to end link, using "game server ping times" is really subject to alot more factors, for instance the programming of the game it's self and is a very poor reflection of the real latency that is occuring due to fragmentation and other problems.

I don't think there would be any real conclusive way to be able to test the latency to various TCP ports, unless you wrote something to open a connection to it and see how long it takes for a banner to come back - or set up a true test environment where you control both end points (Maybe someone could look into this?).

<hr noshade size="1">
"Since light travels faster than sound, people appear bright until you hear them speak."

NetLink Research
 
Top
Sign up to the MyBroadband newsletter
X