This is kinda off-topic, and isn't Ping Plotter specific, but affects PP, so I thought I'd ask...<br><br>One of our Windows NT Workstation machines (service pack 6a) does not have great ping time resolution. Ping times are almost always rounded to the nearest 10ms (i.e., 30ms, 40ms, 50ms, etc). There's the occasional 41ms, 51ms, but it's still not as accurate as it should be.<br><br>Ping times in Ping Plotter are affected by this, as are ping and tracert.<br><br>Just curious if any else has run across this and if there's a way to correct it. Thanks!<br><br>Jason<br><br><br>

Yeah - this is a "feature" of WinNT (oddly, 98 seems to offer better resolution in a lot of cases). I've seen this on my machine pretty much always (I've always attributed it as a feature of NT - with no available configuration to change - if you have NT machines that have better resolution, maybe there's hope).<br><br>My plans for 2.2 originally included a replacement Unix style Ping engine - that would allow better precision (in addition to the default one). Unfortunately, I didn't have time to fully complete this (although there is now support internally for more than one Ping mechanism - including a mostly implemented one that makes external COM method calls to get timing information). I still plan to do this for a future version, however.<br><br>

I "tweaked" this in beta 5 a bit. It shows with a bit higher resoluation, but I'm worried that it may show a ms or 2 low sometimes.<br><br>

I'm a new Ping Plotter user but I know a good bit about WinNT time stuff. When you see increments of 10ms, it is presumably due to the resolution of WinNT's clock on the typical machine. The increment is actually 10.0144ms, and therefore rounding would explain why you sometimes see occasional 51 or whatever. The resolution will most likely be a little less (around 15.6ms) on typical multi-processor machines, and a little bit better (around 7.8ms) if you have old DEC Alpha machines.<br>Although the clock resolution won't increase, to get better timer resolution a programmer can call API timeBeginPeriod(1) before using timer (and corresponding endperiod when done) to get 1ms resolution. Presumably that is what was done in the new option seen in Beta(?)<br><br>Commandline ping/tracert presumably are looking at clock time or using timer without asking for extra resolution (such feature was added shortly after initial release of WinNT).<br><br>

The problem is that the pinging is actually done inside of the ICMP.DLL. Using a timebeginperiod/endperiod doesn't seem to affect the accurace of this API call at all, unfortunately.<br><br>To be able to work around this, I added a "Use high performance timers" option in the advanced options. This actually does call "timebeginperiod/endperiod", and then actually times the API call (rather than trusting the latency as returned by the API call). The problem with this is that ICMP.DLL appears to use windows messaging to do some of its work and high loads seem to really mess with the amount of time it takes for this API call to respond. To work around *this* problem, I boost the priority of the thread during the API call. This works great under NT/2000, but under 98 it completely slams the processor load and makes the system almost unusable. Feel free to play with this "Use high performance times" setting (in Beta 3) to see how it affects the latency if you're running NT/2000.<br><br><br>