[chrony-users] Setting up Chrony with PPS

[Bill Unruh]

William G. Unruh | Canadian Institute for| Tel: [phone]
Physics&Astronomy | Advanced Research | Fax: [phone]
UBC, Vancouver,BC | Program in Cosmology | ***@physics.ubc.ca
Canada V6T 1Z1 | and Gravity | www.theory.physics.ubc.ca/

Miroslav,
After installing 2.3 the 1.24 files remain.
/usr/local/bin/chronyc
/usr/local/sbin/chronyd
looks for /etc/chrony.conf, but not installed
v1.24
/usr/bin/chronyc
/usr/sbin/chronyd
/etc/chrony/chrony.conf
/etc/chrony/chrony.keys

The problem is that you or your system could get confused. If /usr/local/bin
is ahead of /usr/bin (and similarly for sbin) then it will grab the new one
first. Alternatively put /usr/local/sbin/chronyd and /usr/local/bin/chronyc
anywhere and anytime you want to run them, and in any script tht wants to run
them (systemd, /etc/init.d,...)
/etc/chrony.conf and /et/chrony/chrony.keys should be fine.

So is it correct to assume that I have to delete v1.24 chronyc and chronyd
and move the v1.24 chrony.conf and chrony.keys files to /etc?

You can if you wish.

Will the boot up process recognize the new file locations?

You have to tell it.

In order to get PPS to work with ntp, I had to make the following changes and
wondered whether chrony would need something similar?
1. To /boot/config.txt add dtoverlay=pps-gpio,gpiopin=4

I do not know what that is, but probably it is good to leave that in. It is
probably what creates /dev/pps0 tied to the gpio.

2. To /etc/modules add pps-gpio

yes

Deven
--
"unsubscribe" in the subject.
subject.

[Bill Unruh]

210 Number of sources = 6
MS Name/IP address Stratum Poll Reach LastRx Last sample
=======================================================================
#* PPS 0 4 377 13 -19ms[-1103ms] +/- 7321us
#? NMEA 0 4 377 14 -140ms[ -140ms] +/- 138ms
^- kahuna.ruselabs.com 2 6 377 30 +951ms[ -661ms] +/- 114ms
^- zulu.frizzen.net 3 6 377 35 +1433ms[ -178ms] +/- 85ms
^- four10.gac.edu 2 6 377 34 +1341ms[ -270ms] +/- 84ms
^- gopher.fart.website 3 6 377 33 +1249ms[ -362ms] +/- 98ms

I am really worried about your scatter for the PPS, as I was for the scatter
in your assert line. You should NOT be getting a 7ms uncertainty in PPS. It
should be more like 7us-- ie 1000 times better. There is something wrong.
Either your gpio do not raise interrupts and are being read by very bad
polling, or there is something very wrong with your GPS.
I also cannot understand your HORRIBLE offsets from external sources ( 1.3
seconds out) That is absurd. It looks to me like your NMEA is way out as
well. YOur GPS is a piece of junk it looks like.

210 Number of sources = 6
Name/IP Address NP NR Span Frequency Freq Skew Offset Std Dev
========================================================================
PPS 4 3 45 -54883.652 43980.402 -1149ms 44ms
NMEA 4 3 47 -54612.520 50890.305 -1359ms 69ms
kahuna.ruselabs.com 6 4 321 -5743.294 28636.217 +1711ms 666ms
zulu.frizzen.net 6 4 321 -7004.703 23417.387 +1429ms 676ms
four10.gac.edu 6 4 320 -7574.643 21346.463 +1318ms 652ms
gopher.fart.website 7 4 383 -7677.354 15156.406 +1300ms 691ms
How do these look?
How should I configure chrony.conf so that it locks onto PPS as soon as the
signal is available (either after boot up or -- this is a mobile system -- it
is moved outside and acquires GPS)? I don't want a gradual adjustment of
time, it should snap right to the PPS time.

And destroy your filesystem in the process? The system does not like jumps in
time. You can do it at startup of chrony (the -r option) but that should not
happen after the system has been running, or things could get upset.

When chronyd has some NTP sources, you may want to tweak the offset
value of the SHM refclock so the measured offset as reported in
"chronyc sourcestats" is close to zero and the PPS signal can be
locked to it properly.

Using the above numbers, what is the calculation for offset and delay?

Hard to say, but it looks like it is more than 1 sec.

Thanks,
Deven
--
"unsubscribe" in the subject.
subject.

[Bill Unruh]

Hi Bill,

Post by Bill Unruh
I am really worried about your scatter for the PPS, as I was for the scatter
in your assert line. You should NOT be getting a 7ms uncertainty in PPS. It
should be more like 7us-- ie 1000 times better. There is something wrong.
Either your gpio do not raise interrupts and are being read by very bad
polling, or there is something very wrong with your GPS. I also cannot
understand your HORRIBLE offsets from external sources ( 1.3
seconds out) That is absurd. It looks to me like your NMEA is way out as
well. YOur GPS is a piece of junk it looks like.

I have an identical system and will replicate the tests on that unit. I
don't have that system right now, but I'll post results on Monday or Tuesday.

Post by Bill Unruh
And destroy your filesystem in the process? The system does not like jumps in
time. You can do it at startup of chrony (the -r option) but that should not
happen after the system has been running, or things could get upset.

Oh, I don't want to do that. But I would like to configure chrony so that it
quickly adjusts. Quickly being 20 minutes.

Do you have connection to the net when it boots?
You could have a small makestep directive in chrony.conf

The system chrony is running on will not be a time server for any other
systems. The app I'm writing that runs on the system simply needs the most
accurate time to within +/- 5ms. So while I agree with you that PPS should
be delivering much better accuracy, 7321us is pretty close to what I need.

It is symptomatic of problems with your system. As I said, look at your clear
and assert results in /sys/ See if the clear gives more reasonable results (ie
consistant nanoseconds after the second). Your results that you reported
looked really screwy. And these results look really screwy. There is no way a
PPS should be that bad.

[Deven Hickingbotham]

I believe the stats that appear below with show that the system problem
was just poor antenna placement.

When chronyd has some NTP sources, you may want to tweak the offset
value of the SHM refclock so the measured offset as reported in
"chronyc sourcestats" is close to zero and the PPS signal can be
locked to it properly.

Given the figures below, how should offset and delay be calculated?

Finally, any other suggestions for how to setup chrony.conf to quickly
converge to PPS time after startup or acquisition of GPS signal?

chrony.conf:

server 0.us.pool.ntp.org
server 1.us.pool.ntp.org
server 2.us.pool.ntp.org
server 3.us.pool.ntp.org

refclock PPS /dev/pps0 lock NMEA refid PPS
refclock SHM 0 offset 0.5 delay 0.2 refid NMEA noselect


210 Number of sources = 6
MS Name/IP address Stratum Poll Reach LastRx Last sample
========================================================================
#* PPS 0 4 377 19 -24ns[ -194ns] +/-217ns
#? NMEA 0 4 377 17 -148ms[ -148ms] +/-102ms
^- services.quadranet.com 3 10 377 41 -2088us[-2088us] +/- 62ms
^- time-c.nist.gov 1 10 237 224 -37ms[ -37ms] +/- 80ms
^- clock.xmission.com 1 10 377 81 -8631us[-8631us] +/- 25ms
^- leeloo.scurvynet.com 2 10 377 662 -3173us[-3141us] +/- 89ms

210 Number of sources = 6
Name/IP Address NP NR Span Frequency Freq Skew Offset Std Dev
========================================================================
PPS 7 5 96 -0.002 0.011 -24ns 128ns
NMEA 8 7 113 +226.686 403.511 -148ms 5486us
services.quadranet.com 6 3 85m +0.913 1.222 -1893us 635us
time-c.nist.gov 10 8 241m +0.946 0.273 -36ms 955us
clock.xmission.com 17 9 275m +0.881 0.219 -8139us 1216us
leeloo.scurvynet.com 40 21 530m +1.072 0.228 -120us 4307us

Reference ID : 80.80.83.0 (PPS)
Stratum : 1
Ref time (UTC) : Sun Feb 21 15:10:09 2016
System time : 0.000000000 seconds fast of NTP time
Last offset : -0.000000242 seconds
RMS offset : 0.000015393 seconds
Frequency : 3.375 ppm fast
Residual freq : -0.002 ppm
Skew : 0.016 ppm
Root delay : 0.000000 seconds
Root dispersion : 0.000020 seconds
Update interval : 16.0 seconds
Leap status : Normal

[Bill Unruh]

William G. Unruh | Canadian Institute for| Tel: [phone]
Physics&Astronomy | Advanced Research | Fax: [phone]
UBC, Vancouver,BC | Program in Cosmology | ***@physics.ubc.ca
Canada V6T 1Z1 | and Gravity | www.theory.physics.ubc.ca/

I believe the stats that appear below with show that the system problem was
just poor antenna placement.

When chronyd has some NTP sources, you may want to tweak the offset
value of the SHM refclock so the measured offset as reported in
"chronyc sourcestats" is close to zero and the PPS signal can be
locked to it properly.

Given the figures below, how should offset and delay be calculated?
Finally, any other suggestions for how to setup chrony.conf to quickly
converge to PPS time after startup or acquisition of GPS signal?
server 0.us.pool.ntp.org
server 1.us.pool.ntp.org
server 2.us.pool.ntp.org
server 3.us.pool.ntp.org
refclock PPS /dev/pps0 lock NMEA refid PPS
refclock SHM 0 offset 0.5 delay 0.2 refid NMEA noselect

You just copied those out of the chrony docs.
Your offset is -140ms, and you had 500ms offset, so make it 360.
Now your nmea offset fluctuates a lot, but it does not really matter since
it's time is used only to the nearest second anyway.

210 Number of sources = 6
MS Name/IP address Stratum Poll Reach LastRx Last sample
========================================================================
#* PPS 0 4 377 19 -24ns[ -194ns] +/-217ns
#? NMEA 0 4 377 17 -148ms[ -148ms] +/-102ms
^- services.quadranet.com 3 10 377 41 -2088us[-2088us] +/- 62ms
^- time-c.nist.gov 1 10 237 224 -37ms[ -37ms] +/- 80ms
^- clock.xmission.com 1 10 377 81 -8631us[-8631us] +/- 25ms
^- leeloo.scurvynet.com 2 10 377 662 -3173us[-3141us] +/- 89ms

OK, that looks much better. the fluction in the PPS is now ns, not ms.
(I certainly would not believe the time the ns accuracy, but it is probably
good to microseconds).
I am surprized that you have ms fluctuations in the network clocks. Again, it
looks like your network uses smoke signals, rather than wires/wireless, or
your network is really overused.

Your freq and frq skew for nmea below seem really large to me, but I must say
I have not run nmea for a long time.


Anyway, I would say that you are set up.
Look at the assert and clear flags in /sys to see if they are now stable.

210 Number of sources = 6
Name/IP Address NP NR Span Frequency Freq Skew Offset Std Dev
========================================================================
PPS 7 5 96 -0.002 0.011 -24ns 128ns
NMEA 8 7 113 +226.686 403.511 -148ms 5486us
services.quadranet.com 6 3 85m +0.913 1.222 -1893us 635us
time-c.nist.gov 10 8 241m +0.946 0.273 -36ms 955us
clock.xmission.com 17 9 275m +0.881 0.219 -8139us 1216us
leeloo.scurvynet.com 40 21 530m +1.072 0.228 -120us 4307us
Reference ID : 80.80.83.0 (PPS)
Stratum : 1
Ref time (UTC) : Sun Feb 21 15:10:09 2016
System time : 0.000000000 seconds fast of NTP time
Last offset : -0.000000242 seconds
RMS offset : 0.000015393 seconds
Frequency : 3.375 ppm fast
Residual freq : -0.002 ppm
Skew : 0.016 ppm
Root delay : 0.000000 seconds
Root dispersion : 0.000020 seconds
Update interval : 16.0 seconds
Leap status : Normal
--
"unsubscribe" in the subject.
subject.

[Miroslav Lichvar]

I believe the stats that appear below with show that the system problem was
just poor antenna placement.

When chronyd has some NTP sources, you may want to tweak the offset
value of the SHM refclock so the measured offset as reported in
"chronyc sourcestats" is close to zero and the PPS signal can be
locked to it properly.

Given the figures below, how should offset and delay be calculated?

You would adjust the 0.5 offset by 0.148, I'm not sure in which
direction. The goal is to have a smaller offset in the sourcestats
output. But it's not very important as long as the PPS refclock can
"lock" to the NMEA.

Finally, any other suggestions for how to setup chrony.conf to quickly
converge to PPS time after startup or acquisition of GPS signal?

If the clock is not too far, that should happen pretty quickly,
few minutes at most.

If the initial offset of the system clock is large (e.g. the board has
no RTC or battery), you might want to add something like "makestep 1.0
1" to the config, so chronyd is allowed to step the clock if the first
measured offset is larger than 1 second.

[Deven Hickingbotham]

I thought I had chrony 2.3 running on my Raspberry Pi's, but now PPS
doesn't seem to be working. I get the same results described below on
two different systems running Jessie.

Note that PPS Freq Skew and Std Dev are 2000.000 and 4000ms (and these
values don't change on successive runs of sourcestats), so I assume I've
screwed something up, but it is not clear to me what exactly.

Deven


First, I confirm PPS is working:

trying PPS source "/dev/pps0"
found PPS source "/dev/pps0"
ok, found 1 source(s), now start fetching data...
source 0 - assert 1460339841.004927345, sequence: 1353 - clear
0.000000000, sequence: 0
source 0 - assert 1460339842.004927377, sequence: 1354 - clear
0.000000000, sequence: 0
source 0 - assert 1460339843.004927408, sequence: 1355 - clear
0.000000000, sequence: 0
source 0 - assert 1460339844.004927388, sequence: 1356 - clear
0.000000000, sequence: 0
source 0 - assert 1460339845.004927419, sequence: 1357 - clear
0.000000000, sequence: 0


/etc/chrony.conf:

server 0.us.pool.ntp.org
server 1.us.pool.ntp.org
server 2.us.pool.ntp.org
server 3.us.pool.ntp.org

refclock PPS /dev/pps0 lock NMEA refid PPS
refclock SHM 0 offset 0.5 delay 0.2 refid NMEA noselect


chronyc sources and sourcestats:

210 Number of sources = 6
MS Name/IP address Stratum Poll Reach LastRx Last sample
=======================================================================
#? PPS 0 4 0 - +0ns[ +0ns] +/- 0ns
#? NMEA 0 4 377 9 -422ms[ -422ms] +/- 101ms
^- blue.1e400.net 2 9 377 343 -2370us[-2502us] +/- 79ms
^- four10.gac.edu 2 9 377 91 -9823us[-9823us] +/- 89ms
^+ 216.152.240.220 2 9 377 224 +4393us[+4243us] +/- 22ms
^* clock.sjc.he.net 1 9 377 91 -4326us[-4496us] +/- 17ms

210 Number of sources = 6
Name/IP Address NP NR Span Frequency Freq Skew Offset Std Dev
======================================================================
PPS 0 0 0 +0.000 2000.000 +0ns 4000ms
NMEA 9 4 129 +11.345 48.130 -417ms 1011us
blue.1e400.net 20 15 35m +0.169 1.225 -2053us 891us
four10.gac.edu 21 12 42m -0.366 2.259 -3534us 1394us
216.152.240.220 20 12 38m +0.126 1.410 +4425us 1083us
clock.sjc.he.net 21 10 41m -0.186 1.548 -3355us 1079us

[Miroslav Lichvar]

I thought I had chrony 2.3 running on my Raspberry Pi's, but now PPS doesn't
seem to be working. I get the same results described below on two different
systems running Jessie.
Note that PPS Freq Skew and Std Dev are 2000.000 and 4000ms (and these
values don't change on successive runs of sourcestats), so I assume I've
screwed something up, but it is not clear to me what exactly.

Hm, did the configuration of the GPS change? Maybe it's giving fewer
NMEA sentences than before? It looks like the NMEA samples are now
~400 ms off from the expected offset and PPS can't lock to them.
You could try changing the SHM offset to 0.1 and maybe increase the
delay to 0.6 or so, but I'm not sure if that will be enough if the
NMEA offset is changing so much over time.

210 Number of sources = 6
Name/IP Address NP NR Span Frequency Freq Skew Offset Std Dev
======================================================================
PPS 0 0 0 +0.000 2000.000 +0ns 4000ms
NMEA 9 4 129 +11.345 48.130 -417ms 1011us
blue.1e400.net 20 15 35m +0.169 1.225 -2053us 891us
four10.gac.edu 21 12 42m -0.366 2.259 -3534us 1394us
216.152.240.220 20 12 38m +0.126 1.410 +4425us 1083us
clock.sjc.he.net 21 10 41m -0.186 1.548 -3355us 1079us

[Bill Unruh]

William G. Unruh | Canadian Institute for| Tel: [phone]
Physics&Astronomy | Advanced Research | Fax: [phone]
UBC, Vancouver,BC | Program in Cosmology | ***@physics.ubc.ca
Canada V6T 1Z1 | and Gravity | www.theory.physics.ubc.ca/

Is this more in line with what you expected?

Nope. Those are huge uncertainties for network timing. 134ms uncertainty
corresponds to light travel time around the earth uncertainty. I would
expect
more like +- 100 microseconds, not milliseconds.
What is your network link?

I have cable network. Ping 41ms, 20mb downloads speed, 5mp upload.

Should still be a lot better than what you are getting. I also have cable
(Shaw cable in Vancouver)
^* info.physics.ubc.ca 1 6 377 57 -422us[ -465us] +/- 5975us

[Miroslav Lichvar]

My understanding is that chrony.ttyAMA0.sock is a socket created by chronyd and listened to by chronyd
When gpsd starts, it checks to see if the socket exists and writes the PPS data to it.

Yes, that's how it's supposed to work.

Thus chronyd has to be running before gpsd is started. After a reboot of my RPi 2 (debian stretch/sid) I usually kill both daemons and start them manually in the correct order. The default systemd dependencies are wrong or maybe non-existent - who knows with that piece of awfulness - and I don’t want to spend the time investigating

Looking at the Debian packages, the gpsd unit file seems to be the one
provided by upstream, which specifies "After=chronyd.service". But the
chrony service in Debian is named chrony (and not chronyd as in Fedora
for instance), so the ordering dependency is probably ignored. The
gpsd unit file in Debian should use After=chrony.service, or maybe the
upstream version should have both.

[Yan Seiner]

GPS is an Adafruit Ultimate GPS Hat on a Raspberry Pi 2 B. I have two
identical units and have had PPS working with ntp.

Is it possible to bring the PPS signal in on a serial port? I'm doing
something similar but with different hardware; using an internal TTL
level serial port rather than GPIO. I had no luck with GPIO. Also,
I've found that it's best to have a time delay before starting gpsd:

***@AP1:~# cat /etc/rc.local
$( sleep 60 ; /etc/init.d/gpsd start ) &
exit 0

That 60 second delay apparently gives enough time to chrony to do
whatever it needs to do. Make sure you delete SXXgpsd from rc.d if
that's how it's starting.

***@AP1:~# chronyc sources
210 Number of sources = 6
MS Name/IP address Stratum Poll Reach LastRx Last sample
===============================================================================
#- NEMA 0 4 377 11 +141ms[ +141ms]
+/- 251ms
#* PPS 0 4 377 9 +403us[ +404us]
+/- 50ms
^+ vexx.wtfismyip.com 2 6 377 13 +317us[ +320us]
+/- 81ms
^- ntp2.tranzeo.com 2 6 377 10 -2895us[-2893us]
+/- 565ms
^? mirror3.rafal.ca 0 6 0 10y +0ns[ +0ns]
+/- 0ns
^+ zero.gotroot.ca 2 6 377 9 -1172us[-1171us]
+/- 64ms

[Bryan Christianson]

My understanding is that chrony.ttyAMA0.sock is a socket created by chronyd and listened to by chronyd When gpsd starts, it checks to see if the socket exists and writes the PPS data to it.

Isn't that backwards? How would gpsd know what socket to write to?
Generally the model is the writer (which doesn't know what wants to receive) creates the file and the receiver (which knows what it wants to receive) opens it.
We can see that here by the presence of gpsd.sock.
Right?
Tom

Yes - I agree it does seem a little odd, but for good reason

see http://www.catb.org/gpsd/gpsd-time-service-howto.html#_feeding_chrony_from_gpsd

"gpsd, when run as root, feeds reference clock information to chronyd using a socket named /var/run/chrony.ttyXX.sock (where ttyXX is replaced by the GPS receiver’s device name. This allows multiple GPS receivers to feed one chronyd.

No gpsd configuration is required to talk to chronyd. chronyd is configured using the file /etc/chrony.conf or /etc/chrony/chrony.conf. Check your distributions documentation for the correct location. To get chronyd to connect to gpsd using the basic ntpd compatible SHM method add this to use this basic chrony.conf file:”

i.e. gpsd uses a naming convention and the socket as configured in chronyd also uses that same convention


—
Bryan Christianson
***@whatroute.net

[Bill Unruh]

William G. Unruh | Canadian Institute for| Tel: [phone]
Physics&Astronomy | Advanced Research | Fax: [phone]
UBC, Vancouver,BC | Program in Cosmology | ***@physics.ubc.ca
Canada V6T 1Z1 | and Gravity | www.theory.physics.ubc.ca/

The solution is to compile chrony with PPS support (using the
timepps.h header) and use the PPS refclock instead of SOCK. gpsd would
just provide the NMEA timing as a SHM refclock with noselect option,
to which the PPS refclock would be locked as shown in the example in
the chrony manual. This would also be a good opportunity to switch to
a more recent chrony release, 1.24 was actually the first release with
support for reference clocks and there were some bugs fixed since
then.

Okay, this makes sense as I had to recompile ntp to get it working with PPS.
1. Where do I find timepps.h? If I have to download it, where should it be
placed?

You might already have it. Otherwise just google timepps.h
Or install pps-tools from the repository.

You can put it into /usr/include if you wish. Or in the same directory as the
chrony source files, in which case change #include <timepps.h> to #include
"timepps.h" in refclock_pps.c

Debian may well have already installed it.

.

2. Does timepps.h just have to be present or do I have to change it so it
looks for GPIO 4?

Nope it just has to be present.

3. What would be the correct way to configure chrony.conf to recognize PPS?

I suggested one. If you have /dev/pps0 which you say you do,
refclock PPS /dev/pps0

However, as I said, first you have to figure out if your pps0 is really
working. Check if it is assert or clear that gives the correct time.
What you posted on the assert looks very very suspicious.

4. Other than stopping the chrony service before installing v2.3, are there
any other steps that should be taken before updating?
Thanks,
Deven
--
"unsubscribe" in the subject.
subject.

[Deven Hickingbotham]

Tom,

refclock SHM 0 refid GPS precision 1e-1 offset 0.9999 delay 0.2 noselect
refclock SOCK /var/run/chrony.ttyAMA0.sock refid PPS lock GPS

I made the above changes, restarted chrony, waited 10 minutes and:

***@gps ~/SystemFiles $ chronyc sources
210 Number of sources = 6
MS Name/IP address Stratum Poll LastRx Last sample
============================================================================
^~ 1.time.dbsinet.com 2 6 25 +2169ms[+2169ms] +/-80ms
^~ nist.netservicesgroup.com 1 6 7 +2168ms[+2168ms] +/-50ms
^~ pacific.latt.net 3 6 5 +2169ms[+2169ms] +/-77ms
^~ clock.trit.net 2 6 3 +2163ms[+2163ms] +/-28ms
#? GPS 0 4 10y +0ns[ +0ns] +/- 0ns
#? PPS 0 4 10y +0ns[ +0ns] +/- 0ns

This did fix PPS in that it now appears as 'PPS' and not 'PP'.

I'm beginning to think that the reference to chrony.ttyAMA0.sock may not
work for three reasons: isn't that serial access and I need GPIO?;
LastRx indicates no connection; and this looks like it may be messing up
gpsd as it uses ttyAMA0 as a source.

Deven

[Bill Unruh]

OK _ are you stopping gpsd, restarting chronyd then restarting gpsd? Order
matters (well it used to anyway)

Yes, I did that. No change in the chronyc sources output. GPS apps like
cgps -s work.
How can I tell what order the services load during startup?
--

You can start them and stop them while it is running.
killall chronyd
killall gpsd

I do not know how what you are using starts them up, or whether your system
uses systemd or init.
service gpsd start
service chronyd start

might work.

[Deven Hickingbotham]

Post by Miroslav Lichvar
Hm, did the configuration of the GPS change? Maybe it's giving fewer
NMEA sentences than before? It looks like the NMEA samples are now
~400 ms off from the expected offset and PPS can't lock to them.
You could try changing the SHM offset to 0.1 and maybe increase the
delay to 0.6 or so, but I'm not sure if that will be enough if the
NMEA offset is changing so much over time.

Yes, but I didn't expect that it would affect chrony. The update rate
was increased from 1 per second to 10 time per second (since this didn't
affect the PPS signal, I didn't expect it to impact chrony).

Changing the update rate back to 1 per second corrected the issue, but I
need an update rate of at least 5 per second (preferably 10).

Would it be correct to assume that different update rates require
different chrony offsets and delays? And if so, what values should I try?

Thanks,

Deven

[Bill Unruh]

William G. Unruh | Canadian Institute for| Tel: [phone]
Physics&Astronomy | Advanced Research | Fax: [phone]
UBC, Vancouver,BC | Program in Cosmology | ***@physics.ubc.ca
Canada V6T 1Z1 | and Gravity | www.theory.physics.ubc.ca/

Post by Deven Hickingbotham

Post by Miroslav Lichvar
Hm, did the configuration of the GPS change? Maybe it's giving fewer
NMEA sentences than before? It looks like the NMEA samples are now
~400 ms off from the expected offset and PPS can't lock to them.
You could try changing the SHM offset to 0.1 and maybe increase the
delay to 0.6 or so, but I'm not sure if that will be enough if the
NMEA offset is changing so much over time.

Yes, but I didn't expect that it would affect chrony. The update rate
was increased from 1 per second to 10 time per second (since this didn't
affect the PPS signal, I didn't expect it to impact chrony).

??? chrony is using the nmea (ie the reported time from the GPS) to determine
what the seconds are for the PPS. If it does not trust the NMEA time, it
cannot figure out what the "second" time is for the PPS. (PPS ONLY determines
the "microseconds" part of the time, not the seconds part)

Post by Deven Hickingbotham
Changing the update rate back to 1 per second corrected the issue, but I
need an update rate of at least 5 per second (preferably 10).

Why? I think you are confused about something, but I am not sure what.
chrony disciplines the system clock so that it delivers the correct time to
within a few microseconds no matter when you query it. This is completely
indepndent of how often the GPS updates anything. In fact the GPS time is
completely ignored once chrony has settled down. It is far far far more
accurate than the GPS is. ( about 10000 times more accurate).

Post by Deven Hickingbotham
Would it be correct to assume that different update rates require
different chrony offsets and delays? And if so, what values should I try?

I think you need to tell us why you thing you want different update rates
first before this question can be answered.

If the gps delivered one update per day, (but had pps) the accuracy of your
system clock would not change one iota.
So please tell us what it is you are trying to do that makes you think you
want more frequency updates.

Post by Deven Hickingbotham
Thanks,
Deven
--
"unsubscribe" in the subject.
subject.

[Deven Hickingbotham]

Post by Bill Unruh
So please tell us what it is you are trying to do that makes you think you
want more frequency updates.

The faster update rate is not to get GPS time more frequently, but to
get GPS location data more frequently. I'm working on an auto racing
app where the car can be moving at 250 feet per second, so an update
every second is not very accurate for my needs.

Deven

[Bill Unruh]

Post by Bill Unruh
So please tell us what it is you are trying to do that makes you think you
want more frequency updates.

The faster update rate is not to get GPS time more frequently, but to get GPS
location data more frequently. I'm working on an auto racing app where the
car can be moving at 250 feet per second, so an update every second is not
very accurate for my needs.

CAn you not tell the gps to deliver time and location at rates which are
independent of each other? And are you sure that the gps can really update the
position at 10 times per second? There are quite a lot of calculations and
measurements that need to be done to update the position. Is you receiver
capable of doing it. (Just because it says it does something 10 times per sec
does not mean it delivers anything meaningful that quickly).

Deven
--
"unsubscribe" in the subject.
subject.

[Miroslav Lichvar]

Post by Deven Hickingbotham

Post by Miroslav Lichvar
Hm, did the configuration of the GPS change? Maybe it's giving fewer

Yes, but I didn't expect that it would affect chrony. The update rate
was increased from 1 per second to 10 time per second (since this didn't
affect the PPS signal, I didn't expect it to impact chrony).
Changing the update rate back to 1 per second corrected the issue, but I
need an update rate of at least 5 per second (preferably 10).
Would it be correct to assume that different update rates require
different chrony offsets and delays? And if so, what values should I try?

That probably depends on the FW of the GPS. If with one update per
second the NMEA messages were only 0.1 second late, with 10 updates
per second that delay wouldn't have to change, it would still fit
between updates. But if it's 0.5 second late, that can't work with 10
updates per second.

I think you just need to change the offset of the SHM refclock to 0.1
second. The delay can stay as it was.

[Deven Hickingbotham]

Post by Miroslav Lichvar
That probably depends on the FW of the GPS. If with one update per
second the NMEA messages were only 0.1 second late, with 10 updates
per second that delay wouldn't have to change, it would still fit
between updates. But if it's 0.5 second late, that can't work with 10
updates per second.
I think you just need to change the offset of the SHM refclock to 0.1
second. The delay can stay as it was.

Setting offset to 0.1 works for 10, 5, 4, 3, and 2 updates per second.

Setting offset to 0.5 works for updates every 1 and 2.5 seconds. It
does not work for updates every 5 seconds.

If a future version of chrony could support a wide range of gps update
rates without having to modify chrony.conf, that would be appreciated.

Thanks for the support, it has been very helpful and timely!

[Bill Unruh]

Post by Deven Hickingbotham

Post by Miroslav Lichvar
That probably depends on the FW of the GPS. If with one update per
second the NMEA messages were only 0.1 second late, with 10 updates
per second that delay wouldn't have to change, it would still fit
between updates. But if it's 0.5 second late, that can't work with 10
updates per second.
I think you just need to change the offset of the SHM refclock to 0.1
second. The delay can stay as it was.

Setting offset to 0.1 works for 10, 5, 4, 3, and 2 updates per second.
Setting offset to 0.5 works for updates every 1 and 2.5 seconds. It does not
work for updates every 5 seconds.
If a future version of chrony could support a wide range of gps update rates
without having to modify chrony.conf, that would be appreciated.

?? why the demand not to modify chrony.conf? It is there precisely to put in
configuration information.

Your update frequency is something you set once, and a bit of effort to get it
right is a good idea. It is somewhat hard for the program itself to know how
far off the time is since it is the only thing that tells it what the time is.

Post by Deven Hickingbotham
Thanks for the support, it has been very helpful and timely!
--
"unsubscribe" in the subject.
subject.

[Roel Schroeven]

Post by Deven Hickingbotham
Yes, but I didn't expect that it would affect chrony. The update rate
was increased from 1 per second to 10 time per second (since this didn't
affect the PPS signal, I didn't expect it to impact chrony).
Changing the update rate back to 1 per second corrected the issue, but I
need an update rate of at least 5 per second (preferably 10).

Is the GPS connected with a serial link? What baudrate? Default for NMEA
is 4800 bps AFAIK, but if I'm reading Adafruit's website correctly your
Adafruit Ultimate GPS uses 9600 bps by default. Even that may not be
enough for 10 position updates per second. Maybe the GPS simply has
trouble sending all data in the available time.

Can you try increasing the baudrate of the serial connection? See
https://learn.adafruit.com/adafruit-ultimate-gps/faq#faq-4

HTH

Best regards,
Roel
--
"You can fool some of the people all the time, and all of the people
some of the time, but you cannot fool all of the people all of the
time."
-- Abraham Lincoln
"You can fool too many of the people too much of the time."
-- James Thurber

[Deven Hickingbotham]

Post by Roel Schroeven
Is the GPS connected with a serial link? What baudrate? Default for NMEA
is 4800 bps AFAIK, but if I'm reading Adafruit's website correctly your
Adafruit Ultimate GPS uses 9600 bps by default. Even that may not be
enough for 10 position updates per second. Maybe the GPS simply has
trouble sending all data in the available time.
Can you try increasing the baudrate of the serial connection? See
https://learn.adafruit.com/adafruit-ultimate-gps/faq#faq-4

Yes, serial. Baud rate is set to 115200.

[Deven Hickingbotham]

Post by Bill Unruh
CAn you not tell the gps to deliver time and location at rates which are
independent of each other?

Possibly. Several NMEA sentences include time data. Which NMEA
sentence is chrony using?

FYI, ntp does work at the faster update rate.

Post by Bill Unruh
And are you sure that the gps can really
update the
position at 10 times per second? There are quite a lot of calculations and
measurements that need to be done to update the position. Is you receiver
capable of doing it. (Just because it says it does something 10 times
per sec
does not mean it delivers anything meaningful that quickly).

Yes. I've tested a couple of GPS devices that can update at 5 or more
times per second, and they all provide pretty accurate data.

Deven