In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote: > QueryPerformanceCounter() directly off the hardware. Windows > scheduling has no impact here, the drawbacks of tick counts do not
Windows scheduling will cause uncertainty in the time you get from your SNTP requests which you use to calibrate the performance counters. (It will also cause uncertainties in the time of whatever real world event is associated with the times being recorded by your software.) > The issue here is what is the drift of this counter. Once I code my Assuming that you don't have any missed interrupts (if you do, your scheduling uncertainty will be large), one would expect it to be the same as the uncorrected software clock drift, i.e. of the order of 10ppm for a good machine, and up to several 100ppm for poor ones. This is the ntpd frequency value, that is stored in the drift file. This will be the case because the two time sources normally share a common crystal oscillator on the motherboard. I suspect that the real solution here is to have ntpd provide (shared memory?) epoch, slope and intercept data for the high resolution timer. As CPU clock modulation may make RDTSC less useful, it may well be that ntpd moves to using the performance timers to interpolate, when high resolution interpolation is introduce. (These tricks are largely only needed where the kernel doesn't interpolate ticks.) > The problem with any "free" utilities for Windows is that I have to WinZip isn't free, or at least not for commercial use. gzip is open source and comes from the highly respected Free Software Foundation, so you can look at the source code and verify it has no network code, then compile it yourself. WinZip is so widely used that any abuses by it would have been discovered by now. (On the other hand, attempts to go beyond what users consider reasonable have been discovered in earlier versions of Windows!) _______________________________________________ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions