[ntp:questions] Re: PPS and kernel time sync problems.
Ulrich Windl
Ulrich.Windl at RZ.Uni-Regensburg.DE
Thu Jun 22 08:32:46 UTC 2006
ad at heliosphan.co.uk (Adam James) writes:
> Hello timelords,
>
> I have a Garmin GPS25-LVC connected to the serial port of a Via EPIA M
> server, running ntpd 4.2.0a+stable and Linux 2.6.15.7 patched
> with `PPSkit-light-alpha-3328m-2.6.15.1.diff'.
Hi!
Time to make a statement: The patch is "alpha", because it's not complete.
Some kernel interface needed for frequency calibration in hardpps() is
missing. I had tried some work-around, but that's not good.
The problem is here (jsut to get you started somewhere):
pps->state.ecount = do_clock_gettime(CLOCK_REALTIME, &pps->state.etime);
Currently there's no interface to read the current time plus the interpolation
offset consistently.
My hack is this:
+unsigned long do_clock_gettime(int unused_dummy, struct timespec *ts)
+{
+ getnstimeofday(ts);
+ return ts->tv_nsec % tick_nsec;
+}
+EXPORT_SYMBOL(do_clock_gettime);
+
In an attempt to fix it, I tried this:
- return ts->tv_nsec % tick_nsec;
+ return ts->tv_nsec;
and that:
- L_ADD(pps.freq, ftemp);
+ /* ftemp is the required adjustment for the current frequency */
+ if (time_status & STA_PLL) {
+ pps.freq = time_freq;
+ L_ADD(pps.freq, ftemp);
+ }
+ else
+ pps.freq = ftemp;
Regards,
Ulrich
>
> Whilst this combination is functioning, I am a little concerned about
> the output of ntptime:
>
> ntp_gettime() returns code 0 (OK)
> time c82c2865.688c0cc4 Sat, Jun 3 2006 16:25:25.408, (.408387508),
> maximum error 1101 us, estimated error 7 us, TAI offset -1208107020
> ntp_adjtime() returns code 0 (OK)
> modes 0x0 (),
> offset -347.839 us, frequency 0.117 ppm, interval 8 s,
> maximum error 1101 us, estimated error 7 us,
> status 0x2107 (PLL,PPSFREQ,PPSTIME,PPSSIGNAL,NANO),
> time constant 4, precision 0.001 us, tolerance 496 ppm,
> pps frequency 0.117 ppm, stability 0.536 ppm, jitter 2.559 us,
> intervals 63043, jitter exceeded 3769, stability exceeded 576, errors 35639.
>
> Over 50% of the calibration intervals are resulting in errors, which is
> presumably why I am seeing the following in my logs, often over twice a
> minute:
>
> Jun 3 16:15:07 evolution ntpd[25365]: kernel time sync enabled 2107
> Jun 3 16:15:23 evolution ntpd[25365]: kernel time sync disabled 2907
> Jun 3 16:15:42 evolution ntpd[25365]: kernel time sync enabled 2107
> Jun 3 16:17:00 evolution ntpd[25365]: kernel time sync disabled 2307
> Jun 3 16:17:18 evolution ntpd[25365]: kernel time sync enabled 2107
> Jun 3 16:18:43 evolution ntpd[25365]: kernel time sync disabled 2907
> Jun 3 16:19:01 evolution ntpd[25365]: kernel time sync enabled 2107
>
> Status 2907 is STA_PPSERROR, and 2307 is STA_PPSJITTER according to
> timex.h, so this correlates with the output of ntptime above.
>
> In general performance seems good, as shown by the output of ntpq:
>
> remote refid st t when poll reach delay offset jitter
> ==============================================================================
> *GPS_NMEA(0) .GPS. 0 l 10 16 377 0.000 0.003 0.001
> +ntp0.zen.co.uk 195.66.241.3 2 u 37 64 377 16.534 1.844 0.386
> +veracity.mcc.ac 193.62.22.98 2 u 5 64 377 16.541 1.290 2.207
> +ntp0.ja.net .MSF. 1 u 35 64 377 21.979 1.469 0.168
> +ntp1.linx.net .1PPS. 1 u 30 64 377 28.651 0.943 40.229
> +tt01.ripe.net .GPS. 1 u 6 64 377 32.381 1.350 0.903
>
> However, jitter, noise and offset will occasionally shoot up to
> stupidly high levels (I have generated some short term graphs to
> demonstrate this [0]).
>
> Is this likely to be a hardware or wiring issue? I was previously using
> a version of David J. Schwartz's SHM PPS driver, and it appeared to work fine.
>
> Any ideas would be much appreciated.
>
> [0] http://excus.es/ntpd/
>
> --Adam
>
>
> _______________________________________________
> questions mailing list
> questions at lists.ntp.isc.org
> https://lists.ntp.isc.org/mailman/listinfo/questions
More information about the questions
mailing list