Well this is a REALLY weird problem, but it seems like it must be a bug in ICMP.DLL or maybe something even lower in the OS (Windows XP Pro SP2). But on a Dual Core system (AMD tested here, but maybe affects intel Pentium D's also?) Unless I set the Affinity to Core#1, I get completely crazy ping graphs. Jitter all over the place and the graph on the bottom is "blank" with occasional spots of dots. The best way to describe this is with a visual, so here is a screenshot of what I am talking about. You can see where I set the affinity to only allow the process to run on Core#1, everything normalizes and stabilizes. Before that, its total chaos. What do you think is going on here?? Quite strange and I have noticed that even the commandline ping.exe gives negative results on this dualcore cpu.
<img src="/forums/images/graemlins/confused.gif" alt="" />

Hi, Luke.

One of our test machines is a AMD Athlon 64 X2 Dual Core 3800+, running XP SP2 - and we don't see the same issues.

The blanks in the PingPlotter display happens when there is a negative result. I can imagine a situation where the CPUs are reporting back different non-synchronized timings, but we've never seen it. We have seen occasional negative returns, though, with ICMP.DLL (and negative returns from the ping command too). We've not isolated that yet, but it happens seldom enough that it was due to clock drift and time resynchronization from a time server - the resynchronize returning a negative value.

Have you tried any of the other packet types (ICMP Raw Socket, UDP or TCP) to see if the results are any different? With ICMP.DLL, we believe the times returned, but for everything else, we do the timing ourselves (and if there's an issue, we might be able to do something about it).

- Pete

hi Pete. Well, yes I tried some other types... (ICMP Raw Socket & UDP). UDP seemed to work, although the ping times were much higher and seemed to fluctuate much more-- I imagine some core routers might be programmed to deprioritize this type of traffic. ICMP raw socket results were similar to ICMP.DLL results (problematic).

Strangely, a reboot seems to have cleared the issue, perhaps temporarily. I am currently running on the built in gigabit ethernet controller of my Nvidia nforce4 motherboard. I did some searching and came up with the following interesting links:

http://www.dslreports.com/forum/remark,15398295
http://www.dfi-street.com/forum/showthread.php?t=34151
http://forums.nvidia.com/index.php?showtopic=4978&st=80

So it seems there may not be a current working fix for this, and not sure if its a cpu errata in the X2/opteron dual cores or a problem with the nvidia Nforce4 chipset/drivers. Anyway, I am going to switch to the other ethernet port which is controlled by a Marvell Yukon gigE chip. Will see if the results are different.

Very strange bug indeed......... <img src="/forums/images/graemlins/frown.gif" alt="" />

Well I am sad to report that switching to the PCI-express Marvell Yukon Gigabit controller did nothing to help this problem. I have read that this bug is fixed in Windows Vista. I plan to install the Feb 2006 CTP version to test that theory, in the next couple of days when it is released.

Same issue here on a DFI board with 4 gigs of memory and duel core AMD athlon 64 bit. This is the first post i have found on this topic. How do i fix this? I have tried Windows xp Pro and 64 bit addition to. I have had mother board replaced and and 7800gtx o/c from factory replaced to. Do u have or know of a fix for this? Thanks, Chris

We're seeing something similar on our dual core AMD system here. After a reboot, it worked fine. We rebooted it when Luke first posted this message.

Now, roughly 30 days later, the latency numbers are very unreliable. Honestly, we've not looked at it since the problem started getting bad (that happened on March 6th after a reboot on February 20th), so we've not yet had a chance to troubleshoot what's going on here. Since the 6th, though, the "drift" has been increasing - with the average latency going from 105ms on the 6th to 2009ms right now. Luke's clock problems are drifting the opposite direction from ours - here, it seems like our latency is growing rather than getting negative latency numbers.

The ping command is returning the same thing - 150ms, then 2200ms, then 145, then 2300. It's not a latency problems because it doesn't take 2200ms to get the response - those come back immediately - very evident that it's a clock problem.

I'll see if I can look for any patterns later today (like maybe the reporting times from the different CPU cores, if that's the problem). Maybe I can put together a little utility that shows the drift between the cores.

I'm assuming that we're just having time drift problems between the clock cores, and the cores are just not synchronized.

Interesting stuff...

- Pete

I whipped together a little program to compare the timer response (from GetTickCount and QueryPerformanceCounter) from the different CPUs on our test machine that is having problems.

After being turned on for 30 days, the two cores report time differences of about 2.1 seconds. Oddly, the rate of change in the clock is significantly higher at 30 days than it is over the average (right now, the rate of change is to get about a second of variance every 8 days, where it's closer to 15 days for the entire period).

After a reboot, the rate of change is currently 1 second in 130 days, so the problem seems to get worse over time.

I'm not sure what to do with this information. I have a little utility that will report back these times, and will estimate the number of days it will take based on the variation from boot and also the variation when running (it seems to be pretty accurate after collecting data point over 10 minutes or so). If anyone wants this, email support@nessoft.com and ask for it. If we get enough interest, I'll put it out on our servers someplace.

Our test machine is using a NForce4 based KN1 Extreme motherboard with a dual core AMD-64 3800+. I updated to the latest bios and it didn't seem to help.

- Pete

I had the same problem.
The problem is solved in the latest AMD processor driver.

http://www.amd.com/us-en/Processors/TechnicalResources/0,,30_182_871_13118,00.html

See also: http://forums.nvidia.com/index.php?showtopic=4978&st=200
David Martin.