outragous ping

[John]

im posting this in hopes that someone would be kind enough to offer advice as to lower my ping. it's currenty at 1200, its not my router, nor the cable, i've called and checked those, i believe its game stop or some thing else, if anyone could help it would be much welcomed, ty , J.P.

[cely]

The gamespy "ping" is notoriously unreliable. Try pinging ns4.servegame.com from your windows command prompt (assuming you're running windows of course). Even then, keep in mind that the results still might not be indicative of true end to end latency since the NS4 server runs at 80-95% cpu pretty much constantly which doesn't leave much room for windows to process your pings and respond to them in a timely fashion.

Code: Select all

C:\>ping ns4.servegame.com

Pinging ns4.servegame.com [64.94.108.29] with 32 bytes of data:

Reply from 64.94.108.29: bytes=32 time=40ms TTL=113
Reply from 64.94.108.29: bytes=32 time=39ms TTL=113
Reply from 64.94.108.29: bytes=32 time=39ms TTL=113
Reply from 64.94.108.29: bytes=32 time=40ms TTL=113

Ping statistics for 64.94.108.29:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 39ms, Maximum = 40ms, Average = 39ms

C:\>

Does the server in general seem extra laggy to you or are you only concerned about the gamespy "ping"?

[DM_Kim]

When the original cable company I was with sold out to another I had huge lag problems. It took me 3 years to finally get it straightened out between myself and the "new" cable company. In that time I learn a bit about Pings etc, and would send them reports from my system.

As you can see connecting from my computer to NS4 server is not direct. It goes through several hops. The hops listed here are from my computer in Toronto Canada to NS4 Server in Atlanta, USA. (or atleast that's what the IP address indicates) So depending where you live in relation to the NS4 server you may have to go through more or less hops. I direct connect to NS4.

Your lag basically has 4 sources.

A. Your computer CPU, Video Card, Modem and/or router. At times, there are "upgrades" in firm/software that can help if one or all of these are the issue.

B. The NS4 Server it'self. DM events, number of people on or the machine the server is running on has an issue. There is nothing you can do on your end to help reduce these types of lag issues other than if you happen to be a dual logger, make sure the "Ports" in your nwn files are different from one another.

C. Gamespy: If they have an issue. No one can do anything about it.

D. Similar to C. Anywhere long the route your signal takes (hops) any one of the ISP that you signal goes through can have an issue causing lag. Again there is nothing you can do except complain to your own ISP and hope they contact the one having problems. But you need to provide the IP information of the trouble ISP.

Code: Select all

[b]Host Name                                               		IP Address        	Hop    Ping Time[/b]   

* Unknown Host *                                        		000.000.0.0       	   1         	0ms
* Unknown Host *                                        		00.000.00.0       	   2            5ms
* Unknown Host *                                        		00.000.00.000           3            5ms
pos-1-0-0.gw01.mtmc.phub.net.cable.rogers.com                 00.00.000.000     	   4            8ms
so-2-0-0.gw02.bloor.phub.net.cable.rogers.com                 00.000.00.000           5            8ms
* Unknown Host *                                        		00.000.00.000           6         	20ms
cr1-eqix-peer.chg003.internap.net                       	   206.223.119.103         7            20ms
cr1.lax009.inappnet.cr1.chg003.internap.net             	   66.79.146.81            8         	7ms
core1.lax.inappnet-12.cr1.lax009.internap.net           	   66.79.149.130     	   9         	78ms
border1.po1-2g-bbnet1.lax010.pnap.net                   	   216.52.255.13           10      	  140ms    <--- possible cause of lag
* Unknown Host *                                        		63.251.219.146          11        	76ms
* Unknown Host *                                        		64.94.108.29            12           77ms  <----NS4 Server

[cely]

The hops listed here are from my computer in Toronto Canada to NS4 Server in Atlanta, USA. (or atleast that's what the IP address indicates)

WHOIS records aren't always indicative of true geographic location especially for companies or organizations that have an international presence. In this case, the IP's owner's headquarters are located in Atlanta, GA. Deciphering the reverse DNS records is usually a better way to figure out which city an IP address is in. Some service providers use nearby airport codes, others use abbreviations of city names.

border1.po1-2g-bbnet1.lax010.pnap.net

In this case, "lax", is the code for Los Angeles Internation Airport, so we can infer that the NS4 server is somewhere in or around Los Angeles.

Code: Select all

border1.po1-2g-bbnet1.lax010.pnap.net                   	   216.52.255.13           10      	  140ms    <--- possible cause of lag
* Unknown Host *                                              63.251.219.146          11           76ms
* Unknown Host *                                              64.94.108.29            12           77ms  <----NS4 Server

The problem with tools like traceroute, tracert, mtr, smokeping/trace, visualroute, etc is that they all depend on one of two things (sometimes both):
1) Eliciting an ICMP TTL Exceeded packet
2) Eliciting an ICMP Echo Reply packet

The reason this is a problem is that *most* routers (Cisco, Juniper, Foundry, Avici, etc) don't place a high priority on generating those types of ICMP packets. This is usually due to the fact that those packets cannot be generated and switched in hardware, they're handled by the router's processor/control plane. The router's processor is generally busy doing other, more important things like updating routing tables. In some cases, network administrators implement traffic policing on the router's control plane so that the router's processor is not inundated with "low priority requests" such as those sent by ping and traceroute tools.

This is why it is important to consider whether or not the latency is isolated to one router along the path or if the latency persists throughout the rest of the traceroute. In this case, the latency is isolated to one router while actual end to end latency is about 77ms.