[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