[ntp:questions] Come back PPS I miss you!

Dave Hart davehart at gmail.com
Mon Feb 13 10:45:58 UTC 2012


On Sun, Feb 12, 2012 at 05:31, Mark C. Stephens <marks at non-stop.com.au> wrote:
[next line is quoting David Taylor]
>> > Let's know what happens with the Rockwell Jupiter - I don't know that box.
>
> I fired it up, ah ntpd v4.2.7p253 doesn't seem to recognise refclock 31 anymore
> which got a giggle out of me :)
>
> I added the usual server 127.127.31.1 property into the config file but it never
> shows up on the list of peers.

refclock_jupiter.c is compiled into the Windows ntpd 4.2.7p253, but as
you've discovered, a driver developed and tested on unix systems can
be made to compile on Windows without actually working when used :)
If some kind soul provides me a unit, there's a decent chance I could
get it working someday.  The driver code looks pretty clean on a quick
skim, so hopefully there's not much left to tweak to actually have the
driver useful on Windows.  Note the "chance" and "someday", though.
I'm interested in getting as many drivers working on Windows as
possible, but I do have a relatively long NTP-related to-do list and
more pressing issues often must take priority over all NTP work and
play.  I'm also happy to try to help you or anyone else to get it
working without putting hands on a unit myself.  For example,
stripping/commenting out all other sources and running ntpd from a
command prompt with -D3 or -ddd or -d -d -d might highlight the point
of failure.

> So I have tried pps (driver 22)
>
> One thing I noticed, no matter which PPS source I try, (acutime gold, rockwel,
> HP GPS) they always get marked false tickers!
>
> I have removed the min/max poll tokens from the property and I will now leave
> it running to see if it pulls in.
>
> I did have to fudge time1 0.0480 to get offset down..
>
> C:\Documents and Settings\Administrator>ntpq -p
>     remote           refid      st t when poll reach   delay   offset  jitter
> ==============================================================================
> xPPS(1)          .PPS.            0 l    5   64   77    0.000    1.646   3.243
> +ntp             .GPS.            1 s   33   64   77    0.045   -8.206   2.712
> *ntp.melbourne. .ATOM.           1 u   50   64   67   40.217   -0.017   2.216
> -ntp.hobart.   223.252.32.9     2 u   64   64   67   49.914   -4.417  10.535
> +ntp.brisbane. .ATOM.           1 u   55   64   67   31.316    0.897   1.929

If you read up on the intersection and clustering algorithms you will
likely understand ntpd is behaving as designed here.  Assuming you
were starting with the peers billboard shown, it might be worth
commenting out all the remote servers except the one closest to your
PPS in offset, e.g. the first three here, to leave only two sources
with overlapping confidence intervals...  I also note the high PPS
jitter and not quite full reach registers hinting things had not
settled down as much as would be helpful when sharing a peers
billboard and soliciting advice.

Take care,
Dave Hart


More information about the questions mailing list