Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

This is the first time I've seen this and I'm not sure what it means;

64 bytes from 74.125.93.99: icmp_seq=6233 ttl=53 time=545.493 ms  
64 bytes from 74.125.93.99: icmp_seq=6234 ttl=53 time=776.093 ms  
64 bytes from 74.125.93.99: icmp_seq=6235 ttl=53 time=-705.731 ms  
64 bytes from 74.125.93.99: icmp_seq=6236 ttl=53 time=52.549 ms   
64 bytes from 74.125.93.99: icmp_seq=6237 ttl=53 time=44.470 ms  

Has anyone ever seen a negative ping time before? A friend of mine told me he saw it once on a wireless link, and this was over a wireless connection, but.. how does that happen?

share|improve this question
4  
Do you have an AMD processor? –  MaQleod Jul 13 '11 at 23:30
7  
Just a temporary rift in the space-time continuum. Nothing to worry about. Now where did I put the keys to my DeLorean? –  cantfork Jul 14 '11 at 0:40
    
I don't remember specifically which machine I ran the test on, but the only 3 that I could have run it on are all Intel (one Intel desktop, one Macbook Pro, one Mac Mini). –  Jeff Welling Jul 14 '11 at 2:39
10  
Negative ping lag is a glitch in the matrix. It happens when they change something. –  Doc Jul 15 '11 at 15:19

4 Answers 4

up vote 14 down vote accepted

Did NTP or Windows Time Service sync the system clock during the ping?

share|improve this answer
    
Excellent question, that could be it. Unfortunately I don't remember exactly what time I did the ping so I can't check the logs for an NTP sync that lines up. –  Jeff Welling Jul 14 '11 at 2:58
    
That would be freaking odd, but +1 for great troubleshooting point. –  mjb Jul 14 '11 at 3:31
    
With no better answer provided, and not being able to come up with a more plausible solution from the time this happened until now, I'm accepting this answer because I think it's the most likely explanation for how this happened. Thanks. –  Jeff Welling Jul 31 '11 at 11:28
    
I just encountered the same problem on a virtual machine, and can confirm that NTP correcting the time drift was the issue. service ntpd stop on CentOS fixed that (but will create other problems, obviously). See this very interesting question for more info. –  Benjamin Nov 30 '11 at 15:03

I find it hard to believe, but this discussion seems to indicate this is behavior from certain AMD CPUs.

Personally, I wouldn't worry about it and assume it's a conceptual flaw in ICMP... Maybe a packet that went through a different path or something weird involving machines/routers with their clocks set differently.

share|improve this answer
2  
From the linked discussion, I wouldn't lean towards conceptual flaw in ICMP. It appears that AMD has clock skew between the two cores which causes the negative interpretation of the time. –  Evan Jul 14 '11 at 0:13
    
@evan: But 0.7 seconds is a huge discrepancy! –  Mechanical snail Jul 14 '11 at 0:21
2  
the report you get from ping doesn't have anything to do with clocks on external routers, it is the difference in time from when the packet is sent to it's destination and the reply is received back to the host. It is clocked by the host. –  MaQleod Jul 14 '11 at 0:21
    
@Mechanical snail You're right, that's extremely large, but the discussion linked says the skew grows over time. If the processor has been running for an extended period of time .7 seconds is not too absurd. It would be interesting to see if the problem only arises after the processor has been running for a while. –  Evan Jul 14 '11 at 0:27
    
@Evan: I mean that 0.7 seconds is bound to cause more serious bugs than this, so we probably would have already heard of it. –  Mechanical snail Jul 14 '11 at 0:29

Unfortunately, this is not limited to AMD processors, but it seems to affect XP quite a bit. To date, and after a few years of searching for answers, I know a quick fix, but I can't do it to servers that won't reappear by remote after booting.

To reset TCP/IP (and timings), open an admin CMD window and enter the following:

ipconfig /flushdns
arp -d
gpupdate /force
netsh int ip reset null
netsh winsock reset

Now, you MUST reboot. Network adapter reverts to DHCP, so beware remoters.

So what happens here?

For some reason, TCP/IP has a time stamp it uses to calculate timing, and it gets fudged somehow. I used to see it all the time at one location, but it's finally stopped. Unfortunately, it continues at the warehouse I manage. Tonight, all points seem to be stuck at 237ms, but 2 popped back with multiple pings.

pingpath is a very handy utility, and I will be using this more often. Unfortunately, it came up with the same results...

Sad thing, this clears ping miscounts in games also.

note- if you want to see the log file, replace null with a filename, such as c:\log.txt -- Null just means no file (technically)

share|improve this answer

I believe it's a bug in the way the ping command times the packets and is aggravated by AMD processors more than Intel.

The functions that are used for high resolution timing in windows are QueryPerformanceCounter and QueryPerformanceFrequency.

Unfortunately, they are broken for multi-core processors as these processors do not return the same numbers.

The fix to ping is to set thread affinity in ping. I doubt it's doing this which would explain the negative timing. There are also patches from AMD and MS which are supposed to help sort it out.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.