[time-nuts] A new time nut - and a question!

Brian Inglis Brian.Inglis at SystematicSw.ab.ca
Thu Oct 1 12:49:01 EDT 2015


On 2015-10-01 06:05, Christopher Glass wrote:
> Hi list,
>
> I recently got time to build my first stratum-1 GPS timeserver around
> a raspberry-pi (first model) and one of these [1].
> I would ideally like to have it work as a completely standalone time
> source, only getting timing information from the GPS signal it is
> receiving (no network peers). As such, I built ntpd with --with-NMEA,
> and tweaked things around to the point where I *think* I got it
> working, however, my simple question is:
>
> Can somebody tell me whether it's *actually* working? :)
>
> The output I get from "ntpq -c pe -c as -c rl" on the system [2] is
> confusing me a little since I see the GPS source being selected as
> sys_peer, but the event showing says "no_sys_peer". Is this expected
> in case no network source is available?
>
> The last section of the output furthermore shows a difference between
> the "reftime" and "clock" fields. Should I understand that reftime is
> the GPS time and "clock" the state of the system clock? In that case,
> should I see the clocks converge over time?
>
> I apologize if these are easily answered by reading a manual somewhere
> - like I said, it's my very first venture in the world of timekeeping,
> and I would benefit from having somebody explain things to me.

Have you looked at: http://ava.upuaut.net/?p=726

Have you run the GPS module in one place long enough to do a survey
and set it into Stationary mode?

Is PPS enabled and being received?
Have you specified 'prefer' on your server conf line to provide
a time stamp for PPS?
Have you configured a drift file to save frequency and speed up restart?

Have you enabled logging with 'logconfig =allall'?
Check your syslog with dmesg and see what messages have been
or are being issued - there aren't many, except at startup,
even with a bunch of network peers or servers configured:
most are network issues also logged in protostats (below).
More details at: http://www.ntp.org/ntpfaq/NTP-s-trouble.htm

Your pastebin shows:
>     remote           refid      st t when poll reach   delay   offset  jitter
>==============================================================================
>*GPS_NMEA(0)     .GPS.            0 l    3   16    7    0.000   -0.040   0.043
reach is only 7 - 3 samples - needs 8 samples - 377 - to prime the filters
offset 40us and jitter 43us is higher than expected - should be low us

>associd=0 status=c418 leap_alarm, sync_uhf_radio, 1 event, no_sys_peer,
>version="ntpd 4.2.6p5 at 1.2349-o Sat Sep 26 08:08:22 UTC 2015 (1)",
>processor="armv6l", system="Linux/4.1.7+", leap=11, stratum=1,
leap_alarm and leap=11 say unsynced - should be leap_none and leap=00

>precision=-20, rootdelay=0.000, rootdisp=1937.748, refid=GPS,
rootdisp=1937.748 is really high - should be less than 0.5

>reftime=d9b79166.599b08f6 Thu, Oct 1 2015 13:03:02.350,
>clock=d9b79169.f52bbe6f Thu, Oct 1 2015 13:03:05.957, peer=33608, tc=4,
reftime is the last ref clock time used - clock is just the current time

>mintc=3, offset=0.000, frequency=-27.210, sys_jitter=0.043,
offset=0.000 says the system time is not yet set - should be low us
frequency=-27.210 has to stay within 1ppm for it to be an accurate
estimate of your system clock drift - may take some time to settle

>clk_jitter=0.015, clk_wander=0.000
clk_jitter=0.015, clk_wander=0.000 look good - low us and zero

Add ntpq '-c cv' to see your reference clock variables which
should look like:
   associd=0 status=0011 , 1 event, clk_no_reply,
   device="NMEA GPS Clock",
   timecode="$GPRMC,154611,A,5108.3494,N,11411.5630,W,000.0,000.0,011015,014.7,E,D*0E",
   poll=43905, noreply=1, badformat=0, baddata=0, fudgetime1=0.000,
   stratum=0, refid=GPS, flags=0
A few event counts are normal at startup - high means comms problems!

More details on all this at: https://www.eecis.udel.edu/~mills/ntp/html/ntpq.html

Have you created and defined 'statsdir /var/log/ntp/' and
'statistics clockstats loopstats peerstats protostats sysstats'
to record and monitor operation?
'filegen' is not required with default UTC day file dating and rollover.
More details at: https://www.eecis.udel.edu/~mills/ntp/html/monopt.html

If you have network routing, a few good servers close by, or a country
'pool CC.pool.ntp.org iburst' conf will keep your system from becoming
a falseticker if there are any GPS issues.

Email off list if you need more info.
-- 
Take care. Thanks, Brian Inglis


More information about the time-nuts mailing list