[ntp:questions] Re: Please demistify the SHM driver
Paul Croome
Paul.Croome at softwareag.com
Wed Sep 24 09:45:06 UTC 2003
Jerome Oufella <oufella at SPAMBLOCKchez.com> wrote in message news:<bkadr5$t6a$1 at news.univ-mrs.fr>...
> Thanks everyone for your help, these instructions allowed me to write a
> working SHM driver interface to my GPS clock. It seems working actually,
> NTP.
>
> # On the host where the GPS clock is attached :
> localhost:~$ ntpq -p
> remote refid st t when poll reach delay offset jitter
> =========================================================================
> LOCAL(1) LOCAL(1) 9 l 42 64 377 0.000 0.000 0.008
> *SHM(1) SHM(1) 10 l 20 64 377 0.000 -2.813 4.625
>
> # And on a remote host ntp-syncing on the previous one :
> remhost:~$ ntpq -p
> remote refid st t when poll reach delay offset jitter
> ==========================================================================
> LOCAL(1) LOCAL(1) 9 l 34 64 377 0.000 0.000 0.015
> *lift-puurai SHM(1) 11 u 22 32 377 16.467 0.313 1.255
(.....)
Well... 4.625 is not a very good value for the jitter of a GPS refclock.
My GPS (Motorola Oncore) is currently doing:
remote refid st t when poll reach delay offset jitter
==============================================================================
*GPS_ONCORE(0) .GPS. 0 l 9 16 377 0.000 -0.069 0.004
(...more stuff snipped)
But, much more important: If you have a GPS refclock, why the **** are you
using the local clock driver? That's very much a last resort for NTP nets
that don't have access to anything better. And why is your "remote host"
also configured with the local clock driver? There should be at most one
NTP server in the net that syncs to its local clock...
Paul
More information about the questions
mailing list