[Soekris] net4501/FreeBSD NTP problem

[Adam James]

On Sat, 07 Oct 2006 16:41:44 -0400 John Ackermann N8UR <jra at febo.com>
wrote:

Hello,

> I notice a thread that's lived for a while here about problems using
> the kernel PPS discipline on a Soekris net4501 with FreeBSD.
> 
> I'm seeing the same problem, running FreeBSD 6.1, and very hopeful
> for a solution.
> 
> For what little it may be worth, I tried compiling a generic
> (non-Soekris, non-Elan specific) kernel with just PPS_SYNC enabled to
> see if there was a problem in the hardware specific code.  That kernel
> exhibits *really* weird timekeeping behaviour -- an ever increasing
> offset for all sources with very high jitter, and the PPS never
> kicking in.
> 
> Anyway, add me to the list of those who would really like to see a
> solution to this problem.

There seems to be a general misconception that the kernel PLL clock
discipline provided by PPS_SYNC is superior to that provided by ntpd.
If you actually read the PPS driver documentation, you'll notice
this paragraph:

"The driver normally operates like any other driver and uses the same
mitigation algorithms and PLL/FLL clock discipline incorporated in the
daemon. If kernel PLL/FLL support is available, the kernel PLL/FLL
clock discipline can be used instead. The default behavior is not to
use the kernel PPS clock discipline, even if present. This driver
incorporates a good deal of signal processing to reduce jitter using
the median filter and trimmed average algorithms in the driver
interface. As the result, performance with minpoll and maxpoll
configured at the minimum 4 (16s) is generally better than the kernel
PPS discipline. However, fudge flag 3 can be used to enable the kernel
PPS discipline if necessary."

I've contacted Poul-Henning Kamp (who we have to thank for much of
the timekeeping and Soekris specific code in the FreeBSD kernel) about
these issues, and I quote:

"The PPS_SYNC code is generally evil IMO." 

FreeBSD has serial PPSAPI support as standard, and CPU_ELAN_PPS enables
PPSAPI support using the GPIO pins on the net 45xx.

I've been running FreeBSD 6.1 on a Net4501, with a Garmin GPS25-LVC
outputting 1PPS to both the serial port and GPIO pins, for some time.
Accuracy is generally within +/- 10us of UTC, and would be considerably
higher if it were not for the cheap onboard XO (frequency drift is
approximately 7.5PPM).

$ ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
-ntp0.ja.net     .PPS.            1 u   52   64  377   27.343    1.107   0.313
+ntp0.esat.net   .GPS.            1 u   20   64  377   39.086    1.073   2.433
-maverick.mcc.ac 193.62.22.66     2 u   25   64  377   32.347    1.216   0.414
-veracity.mcc.ac 193.62.22.98     2 u   58   64  377   32.695    1.164   0.298
-utserv.mcc.ac.u 193.62.22.66     2 u   65   64  377   32.661    1.326   0.276
-gi5-48.telford4 195.66.241.3     2 u   58   64  377   32.459    1.002   0.343
+GPS_NMEA(0)     .GPS.            0 l   15   16  377    0.000   -0.010   0.015
oPPS(0)          .PPS.            0 l    3   16  377    0.000   -0.009   0.015

$ ntpq -crv
status=2194 leap_none, sync_atomic/PPS, 9 events, event_peer/strat_chg,
version="ntpd 4.2.2 at 1.1532-o Mon Jul  3 23:51:22 UTC 2006 (2)",
processor="i386", system="FreeBSD/6.1-RELEASE-p3", leap=00, stratum=1,
precision=-16, rootdelay=0.000, rootdispersion=0.481, peer=49506,
refid=PPS, reftime=c8d29e1e.7a6ea690  Sat, Oct  7 2006 21:43:58.478,
poll=4, clock=c8d29e2c.366b31f1  Sat, Oct  7 2006 21:44:12.212, state=4,
offset=-0.009, frequency=7.465, jitter=0.015, noise=0.015,
stability=0.000, tai=0, access_policy="open"

Noise and jitter never go below 0.015 due to (as far as I can tell) the
available precision in reading the clock:

# ./precision
precision  = 9 usec after 5 loops
resolution = 9 usec after 0 loops
     (The resolution is less than the time to read the clock -- Assume 1us)
log2(resolution) = -20, log2(precision) = -17

If you were to replace the onboard XO with an OCXO or rubidium
standard, then I think it would be quite possible to reach an accuracy
within hundreds of nanoseconds of UTC.

Feel free to contact me if you need any further information on how I
got it all working.

--Adam