Thread: WTF happened to my ping?

Normaly my ping is like 100-80

I was playing the other day and i had a 50.

Start simple. Based on your tracert it appears you have cable internet.

test 1) ping your cable modem. ping 192.168.100.1 -n 250
test 2) ping your public gateway ping 63.165.191.1 -n 250
test 3) ping final peer. ping 66.18.0.138 -n 250

Test 1 will indicate a local issue with your own equipment or users
Test 2 will indicate a problem with the cable network
Test 3 will indicate a problem with your ISPs Peer-Backbone


Quoted since this is not really specific to your problem

Originally Posted by GReYVee

If I am correct, you have a small local provider in Fort Worth. I have taken a look and can imply the following about them.
Not an ILEC
They own very few fiber rings, or operate almost purely on circuits
Small cable plant to maintain.

Further look
Business service lacks contracts
Their packages / channel ranges assume QAM 256.
Phone service being a CLEC assumes VOIP.

Points to a problem with either
their peer (sprint).
Or
their plant.

Let us hope for the latter. QAM 256 is susceptible to issues with CNR. This will cause latency. Will also cause shitty phone service. Easy to fix.
If it's the former.. good luck.

Man, doesn't texas have fios? I'd go with that if I could :P. Although it's a very different method of solving your problem.

Originally Posted by WileECyte

Originally Posted by Braddoc

hop 3 isn't necessarily a problem. there are many factors with why it's response time is higher than the rest. what makes the traceroute time unreliable is that the router has to decrement the ttl, discard the packet, create a new one, and then forward it on the wire. only one of those functions is the routers primary task; which is to route. the most important thing to look at is how long it takes for the last hop to respond. if you had high response times on every hop after hop 3, i would definitely call it the problem. but you don't. in fact, you have great traceroute response times at the final hop. therefore, i would conclude that you have no latency passing icmp traffic to the final hop.

you could try to run a 100 or 1000 count ping test against that hop and see if you have any rtt's that spike. but again, ping is a different protocol than what your game would run on. routers and firewalls may treat icmp traffic differently than the tcp port your game runs.

the best quality test that you can perform is to attempt to find a linux live cd, and run either tcpping or tcptraceroute to the host on the tcp port your game runs on. the only reason i mention linux is because windows nerfed the ability to run utilities like this since windows xp service pack 2.

I'd be willing to bet though that the router at hop 3 is overloaded, and he's dropping packets. I've seen it far too many times where one hop there's a spike in the latency and you end up dropping 25% or more of your packets.

he's not dropping packets in the tests he's posted. tracert sends 3 packets, one after the next once the first is received, with a maximum timeout of 3 seconds by default. he's getting 3 responses, so no packets are dropping.

there is no latency caused by hop 3 on any of the post hop 3 packets, as seen by the excellent response times in the rest of the traceroute.

Originally Posted by GReYVee

Start simple. Based on your tracert it appears you have cable internet.

test 1) ping your cable modem. ping 192.168.100.1 -n 250
test 2) ping your public gateway ping 63.165.191.1 -n 250
test 3) ping final peer. ping 66.18.0.138 -n 250

Test 1 will indicate a local issue with your own equipment or users
Test 2 will indicate a problem with the cable network
Test 3 will indicate a problem with your ISPs Peer-Backbone

good ideas on the tests, but again, given the decent rtt times (~7ms avg) from his final hop, i don't think that you will find any latency issues. even if you do, it will be latency with ICMP traffic, not TCP like you would find in game.

192.168.100.1 isn't his cable modem, though. it isn't even in his network trace. maybe you mean 192.168.0.1? but even then that will be his firewall/router (whatever device is supplying the NAT'd address).

Originally Posted by Too Much Damage

can you speed walk me through this? I have a live cd or three.

if i get a break tomorrow, i'll do a writeup on how to get the tcpping/tcptraceroute going on a linux livecd. the only livecd i have is centos, though. it will more than likely be different on your distro. which do you have?

Originally Posted by Braddoc

192.168.100.1 isn't his cable modem, though. it isn't even in his network trace. maybe you mean 192.168.0.1? but even then that will be his firewall/router (whatever device is supplying the NAT'd address).

It is an internal diagnostic address common to all DOCSIS cable modems. If you have cable try pinging it should work unless there is a clash with your internal scope (which in his case isnt a problem since its likely 192.168.0.0/24)

Originally Posted by GReYVee

Originally Posted by Braddoc

192.168.100.1 isn't his cable modem, though. it isn't even in his network trace. maybe you mean 192.168.0.1? but even then that will be his firewall/router (whatever device is supplying the NAT'd address).

It is an internal diagnostic address common to all DOCSIS cable modems. If you have cable try pinging it should work unless there is a clash with your internal scope (which in his case isnt a problem since its likely 192.168.0.0/24)

well, you learn something new... and stupid... every day.