[ntp:questions] PSYCHO PC clock is advancing at 2 HR per second

unruh unruh at invalid.ca
Tue Mar 20 17:28:54 UTC 2012


On 2012-03-20, Dave Hart <hart at ntp.org> wrote:
> On Tue, Mar 20, 2012 at 12:28, Miroslav Lichvar <mlichvar at redhat.com> wrote:
>> On Tue, Mar 20, 2012 at 02:59:12AM +0000, Dave Hart wrote:
>>> Although it's the first time I've seen such, it appears the offset and
>>> frequency calculations both ended up overflowing. ?I would have
>>> guessed bad input should have appeared in peerstats before loopstats
>>> but I didn't find anything unusual.
>>
>> This sounds familiar. Perhaps the OP is hitting the bug 2156 fixed
>> recently?
>
> Very good point.  He's using p259 which has bug 2156 which could
> trigger a divide by zero if the LOCAL driver is selected.  p263 and
> later fix that bug.
>
>> If the emulated adjtime on Windows doesn't apply the 500 ppm
>> limit, it could have explained the huge frequency error.
>
> adj_systime() in ports/winnt/ntpd/nt_clockstuff.c does enforce 500 PPM
> limit on what it asks of Windows.  In order to emulate adjtime()
> called at the beginning of frequency calibration to eliminate the
> entire initial offset, any correction of greater magnitude than 500 us
> results in 500 us being applied and the remainder carried over to the
> next once-per-second adj_systime().
>
> On balance, I don't think bug 2156 explains what Ron reported.  The
> division by zero in question wouldn't have resulted in the loopstats
> offset and frequency being -1.#IND (which is, BTW, slightly odd --
> there are more references to -1.#INF and 1.#IND) and -1.#IO.  Also,
> even with a wildly unpredictable or large argument passed to
> adj_systime(), no more than 500 PPM should make it through to Windows.
>
> David Taylor is right that it is normal for Windows to keep running
> the clock at whatever rate was last set after the program setting the
> rate goes away.  It's also true that Windows does not have any rate
> limits itself -- you can easily tell Windows to advance the clock 1
> usec per tick (nominally 15.625 msec), one hour per tick.  Unless I
> misread the nt_clockstuff.c code, it shouldn't be possible to get ntpd
> to set the Windows clock rate more than 500 PPM from nominal.

Presumably it could run away. It sets it at 500PPM on this cycle. The
next reading then comes early and it again applies a 500PPM extra, etc.
That would lead to an exponential runaway, and the hour per tick that he
was seeing wouldn't it?


>
> Thanks,
> Dave Hart



More information about the questions mailing list