Martin Burnicki wrote: > Terje, > As you've already mentioned a possible improvement would be indeed to try to > determine the TSC sample with the lowest latency in order to decrease the > interpolation jitter between several tick intervals.
Right > > However, there's still the frequency of the PerformanceCounter which is used > as returned by the OS. The real frequency is also off the nominal frequency > which results in an system dependent estimation error proportional to the > length of the estimation interval. This could be avoided if the real > frequency of the PerformanceCounter would be computed and the computed > frequency be used for the estimated system time. My dual loop approach would indeed measure/tweak the highres counter frequency by comparing it to the (ntpd-corrected) system clock, instead of depending upon whatever the OS thinks it is. The good thing about using the PerformanceCounter is that you can either read the frequency as well on every tick, or you can do so if the count seems off: This allows a way to notice if/when the OS has turned on some kind of cpu throttling that affects the counter frequency, but the best way to do this would be to hook into the OS/power driver with a callback which is notified each time the frequency changes. Terje -- - <[EMAIL PROTECTED]> "almost all programming can be viewed as an exercise in caching" _______________________________________________ questions mailing list [email protected] https://lists.ntp.org/mailman/listinfo/questions
