Negative ping time?

Question

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?

Just a temporary rift in the space-time continuum. Nothing to worry about. Now where did I put the keys to my DeLorean? — juggler, Jul 14 '11 at 00: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 02:39
Negative ping lag is a glitch in the matrix. It happens when they change something. — James T Snell, Jul 15 '11 at 15:19

score 15 · Accepted Answer · answered Jul 14 '11 at 02:48

15

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

answered Jul 14 '11 at 02:48

Hydaral

1,722
9
11

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 02:58
That would be freaking odd, but +1 for great troubleshooting point. – mbb Jul 14 '11 at 03: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](http://stackoverflow.com/questions/117422/how-can-i-resolve-the-drifting-clock-for-my-virtual-machine) for more info. – BenMorel Nov 30 '11 at 15:03

score 4 · Answer 2 · answered Jul 13 '11 at 23:33

4

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.

answered Jul 13 '11 at 23:33

James T Snell

5,892
1
22
33

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 00:13
@evan: But 0.7 seconds is a *huge* discrepancy! – Mechanical snail Jul 14 '11 at 00: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 00: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 00: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 00:29

score 1 · Answer 3 · edited Jan 13 '14 at 22:18

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.

score 1 · Answer 4 · edited Sep 23 '13 at 03:38

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)

Negative ping time?

4 Answers4

Linked

Related