[ntp:questions] Re: SHM refclock not being selected

David Schwartz davids at webmaster.com
Sun Mar 13 02:40:00 UTC 2005

"John Ackermann N8UR" <jra at febo.com> wrote in message 
news:mailman.13.1110633714.576.questions at lists.ntp.isc.org...

> In order to use a PPS source with Linux 2.6.x, I've been running David 
> Schwartz' shm_linux_clock driver with an HP3801A GPSDO as the external 
> refclock.  I am getting very good reported results and the SHM clock 
> consistently has the lowest jitter of any of my servers, but for some 
> reason ntpd doesn't select it as the source.  Here's the ntpq -p output 
> after a week of operation:

    That's kind of strange.

>     remote           refid      st t when poll reach   delay   offset 
> jitter
> ==============================================================================
> +GPS_HP(0)       .GPS.            0 l   18   64  377    0.000   -2.045 
> 3.867
> +SHM(0)          .PPS.            0 l   54   64  377    0.000    0.882 
> 0.033
> *tock.febo.com   .PPS.            1 u  411 1024  377   10.362    5.926 
> 0.192
> +time-B.timefreq .ACTS.           1 u  411 1024  377   74.705   -5.855 
> 0.759
> -ntp1.usno.navy. .USNO.           1 u  451 1024  175   79.246   23.077 
> 0.253
> -ntp2.usno.navy. .USNO.           1 u  452 1024  377   79.070   26.126 
> 4.196

    Now, you have two stratum zero closk, they're both perfectly reachable, 
and have good jitter.

> Selecting "tock" as the survivor isn't a bad thing, as it is a FreeBSD 
> machine sitting on the local subnet, and has two stratum 0 refclocks, but 
> I would think that since the SHM clock *always* has lower delay and jitter 
> (as well as sane offset values), it should end up being the survivor.

    That's what I would think. It's also odd that it would take a stratum 
one reference over a stratum zero one.

> Should I be using the "prefer" keyword to force selection of the SHM 
> clock?  Or is there some other trick I should be playing with this 
> configuration?

    Can you post your configuration? I'm wondering if perhaps you have some 
'restrict default' lines without the appropriate override. It may help to 
add this:

restrict mask

> By the way -- I was getting absolutely horrendous, unusable time from this 
> machine until I recompiled the 2.6.9 kernel with HZ=100, and selected 
> "clock=pit" at boot time (not sure which of the two changes is making the 
> most significant impact; I wasn't in a position to experiment through 
> multiple reboots).

    Now that's strange. Does this machine have one CPU or more than one? 
What type?


More information about the questions mailing list