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

64 bytes from icmp_seq=6233 ttl=53 time=545.493 ms  
64 bytes from icmp_seq=6234 ttl=53 time=776.093 ms  
64 bytes from icmp_seq=6235 ttl=53 time=-705.731 ms  
64 bytes from icmp_seq=6236 ttl=53 time=52.549 ms   
64 bytes from 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?

  • 4
    Do you have an AMD processor?
    – MaQleod
    Commented Jul 13, 2011 at 23:30
  • 9
    Just a temporary rift in the space-time continuum. Nothing to worry about. Now where did I put the keys to my DeLorean?
    – juggler
    Commented Jul 14, 2011 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). Commented Jul 14, 2011 at 2:39
  • 12
    Negative ping lag is a glitch in the matrix. It happens when they change something. Commented Jul 15, 2011 at 15:19

4 Answers 4


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

  • 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. Commented Jul 14, 2011 at 2:58
  • That would be freaking odd, but +1 for great troubleshooting point.
    – mbb
    Commented Jul 14, 2011 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. Commented Jul 31, 2011 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.
    – BenMorel
    Commented Nov 30, 2011 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.

  • 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
    Commented Jul 14, 2011 at 0:13
  • @evan: But 0.7 seconds is a huge discrepancy! Commented Jul 14, 2011 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
    Commented Jul 14, 2011 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
    Commented Jul 14, 2011 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. Commented Jul 14, 2011 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)


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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .