time-nuts@lists.febo.com

Discussion of precise time and frequency measurement

View all threads

A new time nut - and a question!

CG
Christopher Glass
Thu, Oct 1, 2015 12:05 PM

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.

Thanks for your time

  • Chris

Links:

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. Thanks for your time - Chris Links: --------- [1]: http://ava.upuaut.net/store/index.php?route=product/product&path=59_60&product_id=95 [2]: http://pastebin.ubuntu.com/12631346/
DJ
David J Taylor
Thu, Oct 1, 2015 4:02 PM

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:

[]
Thanks for your time

  • Chris

---==

Chris,

I used no special build on NTP.  I've been asked the same question, and put
some notes sent in by users on my Web site:

http://www.satsignal.eu/ntp/Raspberry-Pi-quickstart.html#stand-alone

Perhaps there's something there?

Cheers,
David

SatSignal Software - Quality software written to your requirements
Web: http://www.satsignal.eu
Email: david-taylor@blueyonder.co.uk

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: [] Thanks for your time - Chris =================================== Chris, I used no special build on NTP. I've been asked the same question, and put some notes sent in by users on my Web site: http://www.satsignal.eu/ntp/Raspberry-Pi-quickstart.html#stand-alone Perhaps there's something there? Cheers, David -- SatSignal Software - Quality software written to your requirements Web: http://www.satsignal.eu Email: david-taylor@blueyonder.co.uk
CG
Christopher Glass
Thu, Oct 1, 2015 4:44 PM

Hi David,

Thanks for the pointer - but the driver I am using is type 20 (NMEA),
so that flag1 is documented as enabling/disabling of PPS signal
processing instead.

After some time, the output of "ntpq -c pe -c as -c rl" seemed to
stabilize as 1. The GPS reference seems to be used correctly (as
show by the leading "o" in ntpq -c pe" output.

However I still don't understand the "reftime/clock" difference, and
it seems the two dates are drifting from each other rather than
converging, which is unexpected (to me, as a newbie).
The frequency field keeps changing, so should I understand that the
frequency field is adjusted automatically until the times are in sync?

On Thu, Oct 1, 2015 at 6:02 PM, David J Taylor
david-taylor@blueyonder.co.uk 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:

[]
Thanks for your time

  • Chris

---==

Chris,

I used no special build on NTP.  I've been asked the same question, and put
some notes sent in by users on my Web site:

http://www.satsignal.eu/ntp/Raspberry-Pi-quickstart.html#stand-alone

Perhaps there's something there?

Cheers,
David

SatSignal Software - Quality software written to your requirements
Web: http://www.satsignal.eu
Email: david-taylor@blueyonder.co.uk


time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Hi David, Thanks for the pointer - but the driver I am using is type 20 (NMEA), so that flag1 is documented as enabling/disabling of PPS signal processing instead. After some time, the output of "ntpq -c pe -c as -c rl" seemed to stabilize as [1]. The GPS reference seems to be used correctly (as show by the leading "o" in ntpq -c pe" output. However I still don't understand the "reftime/clock" difference, and it seems the two dates are drifting from each other rather than converging, which is unexpected (to me, as a newbie). The frequency field keeps changing, so should I understand that the frequency field is adjusted automatically until the times are in sync? [1]: http://pastebin.ubuntu.com/12632650/ On Thu, Oct 1, 2015 at 6:02 PM, David J Taylor <david-taylor@blueyonder.co.uk> 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: > > [] > Thanks for your time > > - Chris > =================================== > > Chris, > > I used no special build on NTP. I've been asked the same question, and put > some notes sent in by users on my Web site: > > http://www.satsignal.eu/ntp/Raspberry-Pi-quickstart.html#stand-alone > > Perhaps there's something there? > > Cheers, > David > -- > SatSignal Software - Quality software written to your requirements > Web: http://www.satsignal.eu > Email: david-taylor@blueyonder.co.uk > _______________________________________________ > time-nuts mailing list -- time-nuts@febo.com > To unsubscribe, go to > https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there.
BI
Brian Inglis
Thu, Oct 1, 2015 4:49 PM

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@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

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@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