Martin Burnicki wrote: > As a consequence of the above I'd say using RDTSC directly instead of QPC is > a step in the wrong direction. From what I've seen adding the /usepmtimer > switch should fix problems on systems where TSC is used even though it is > not reliable.
TSC has one huge advantage, in that it costs almost nothing to read it (10-25 clock cycles depending upon cpu model), but power frequency adjustments and especially SMP systems cause trouble. > > This should also make it obsolete to nail down all threads to a single CPUm > as suggested in bug #1124: > https://support.ntp.org/bugs/show_bug.cgi?id=1124 > > Or am I missing something? The alternate timers, being bus-based, cost one or two orders of magnitude more time to query, so for a system which needs very frequent timing info, the overhead needed to make RDTSC useable (processor locking, frequency stepping callbacks etc) can make sense. NTP in client modus is almost certainly not in this category, with less than 1000 calls per second. An NTP server with lots of clients won't be running on Windows anyway. :-) I do know that Intel intends to make processor-based timers more useful by setting up a counter which always runs at a fixed rate, independent of any frequency power stepping. On such a cpu RDTSC would again be the best choice, but hopefully the OS would realize this and start to use it for QPC. Terje -- - <Terje.Mathisen at tmsw.no> "almost all programming can be viewed as an exercise in caching" _______________________________________________ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
