martin.burnicki at meinberg.de
Thu Mar 12 09:04:21 UTC 2009
Dave Hart wrote:
> On Mar 11, 8:55 am, Martin Burnicki <martin.burni... at meinberg.de>
>> Dave Hart wrote:
>> > I have released a new test version of 4.2.4p6 with numerous Windows-
>> > specific improvements compared to the baseline 4.2.4p6. Since my last
>> > release, the most significant change is to read the processor cycle
>> > counter using the RDTSC instruction directly when it is equivalent to
>> > QueryPerformanceCounter. When it is not equivalent, ntpd is allowed
>> > to roam freely across all logical processors once again.
>> 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.
>> This should also make it obsolete to nail down all threads to a single
>> CPUm as suggested in bug
>> Or am I missing something?
> I think so. This version only uses RDTSC if QueryPerformanceCounter
> is using RDTSC. If the HAL is using a different timer for QPC, this
> version uses QPC.
The question about "missing something" was intended to be related to the way
QPCs under certain HALs/CPUs/mainboard are working. ;-))
> Regarding bug 1124 with this version threads are not nailed down to a
> particular processor except when RDTSC underlies QPC.
Anyway, this sound pretty reasonable. However, you still may have to make
sure RDTSC calls are not messed up by other effects (clock frequency
changes, ...) which QPC seems to try to correct.
More information about the questions