Re: [chrony-users] Not getting time from gpsd
Ok I've got the new refclock line in place and statistics are logging. I'll check it in a couple days. Quick question on binary mode. It's a ublox and GPSD supports it. Would I get better results if I force the module into binary mode? On Aug 10, 2016 3:24 AM, "Miroslav Lichvar" wrote: > On Tue, Aug 09, 2016 at 04:22:56PM -0400, Chris Greenman wrote: > > Ok I set it to 0.0065 offset. Here's my chrony.conf > > > > pool pool.ntp.org > > driftfile /var/lib/chrony/drift > > allow > > refclock SHM 0 refid GPS offset 0.065 > > #refclock SHM 0 refid GPS precision 1e-1 offset 0. delay 0.2 > > makestep 1 -1 > > > > and here is the chrony sources output: > > > > === > > #* GPS 0 4 37712 +2112us[+2967us] +/- > > 325us > > ^- orchid.sidereal.ca2 61719+11ms[ +12ms] +/- > > 40ms > > ^- static-96-244-96-19.bltmm 2 61719+11ms[ +12ms] +/- > > 40ms > > ^- hydrogen.constant.com 2 61718+14ms[ +15ms] +/- > > 32ms > > ^- host2.kingrst.com 2 61519 +9078us[ +10ms] +/- > > 100ms > > Ok, so now it seems the correction should be actually about 10 > milliseconds smaller. This means the GPS offset is not very stable, > which is normal with message based (e.g. NMEA) samples. The value > specified by the delay option should include this interval. If you set > it to 0.2, the assumed error of the source will be +/- 0.1 seconds. As > long as the GPS time (corrected by the offset) doesn't move from the > true time by more than 0.1 seconds, the error interval will contain > the true time and the source will always agree with other good > sources. > > If you enable the statistics log and run it for few days, you will > probably better see how much the offset moves. If you don't have time > for that, I think delay of 0.2 seconds should be good enough. > > The recommended refclock line in this case would be: > > refclock SHM 0 refid GPS offset 0.060 delay 0.2 minsamples 64 > > The assumed error of the GPS source will now be similar or larger than > the NTP sources, so if they are online, GPS should be ignored or > combined with them (+ symbol in the sources output). Only when the NTP > sources are offline the synchronization will use GPS alone. > > -- > Miroslav Lichvar > > -- > To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org > with "unsubscribe" in the subject. > For help email chrony-users-requ...@chrony.tuxfamily.org > with "help" in the subject. > Trouble? Email listmas...@chrony.tuxfamily.org. > >
Re: [chrony-users] Not getting time from gpsd
I CAN hook it up for PPS but it will require cracking open the puck and it's not that crucial for my use anyway. On Thu, Aug 11, 2016 at 6:39 PM, Bill Unruh wrote: > > On Thu, 11 Aug 2016, Chris Greenman wrote: > > >> Ok I've got the new refclock line in place and statistics are logging. >> I'll check it in a couple days. >> >> >> Quick question on binary mode. It's a ublox and GPSD supports it. >> Would I get better results if I force >> the module into binary mode? >> > > Maybe, maybe not. I doubt it would make that much of a difference. Now if > you > activated PPS on it, that would make a difference of at least a factor of > 1000. But then you may well not need that. > What your results say is that you now have an uncertainty of about 10ms. I > suspect ( but someone who knows the chipset better may be able to > contradict > me) that binary mode will not be that much better. > > > > >> >> On Aug 10, 2016 3:24 AM, "Miroslav Lichvar" wrote: >> On Tue, Aug 09, 2016 at 04:22:56PM -0400, Chris Greenman wrote: >> > Ok I set it to 0.0065 offset. Here's my chrony.conf >> > >> > pool pool.ntp.org >> > driftfile /var/lib/chrony/drift >> > allow >> > refclock SHM 0 refid GPS offset 0.065 >> > #refclock SHM 0 refid GPS precision 1e-1 offset 0. delay 0.2 >> > makestep 1 -1 >> > >> > and here is the chrony sources output: >> >> > >> === >> > #* GPS 0 4 37712 >> +2112us[+2967us] +/- >> > 325us >> > ^- orchid.sidereal.ca2 61719+11ms[ >> +12ms] +/- >> > 40ms >> > ^- static-96-244-96-19.bltmm 2 61719+11ms[ >> +12ms] +/- >> > 40ms >> > ^- hydrogen.constant.com 2 61718+14ms[ >> +15ms] +/- >> > 32ms >> > ^- host2.kingrst.com 2 61519 +9078us[ >> +10ms] +/- >> > 100ms >> >> Ok, so now it seems the correction should be actually about 10 >> milliseconds smaller. This means the GPS offset is not very stable, >> which is normal with message based (e.g. NMEA) samples. The value >> specified by the delay option should include this interval. If you >> set >> it to 0.2, the assumed error of the source will be +/- 0.1 seconds. >> As >> long as the GPS time (corrected by the offset) doesn't move from the >> true time by more than 0.1 seconds, the error interval will contain >> the true time and the source will always agree with other good >> sources. >> >> If you enable the statistics log and run it for few days, you will >> probably better see how much the offset moves. If you don't have >> time >> for that, I think delay of 0.2 seconds should be good enough. >> >> The recommended refclock line in this case would be: >> >> refclock SHM 0 refid GPS offset 0.060 delay 0.2 minsamples 64 >> >> The assumed error of the GPS source will now be similar or larger >> than >> the NTP sources, so if they are online, GPS should be ignored or >> combined with them (+ symbol in the sources output). Only when the >> NTP >> sources are offline the synchronization will use GPS alone. >> >> -- >> Miroslav Lichvar >> >> -- >> To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org >> with "unsubscribe" in the subject. >> For help email chrony-users-requ...@chrony.tuxfamily.org >> with "help" in the subject. >> Trouble? Email listmas...@chrony.tuxfamily.org. >> >> >>
Re: [chrony-users] Not getting time from gpsd
it's a usb puck. so no. Actually I haven't actually looked but typical USB is +5v data+ data- and gnd. As far as I know the only place the pps signal is available is inside the puck between the GPS module and the usb interface. like I said I COULD crack it open and run a new cable that included the pps line. On Fri, Aug 12, 2016 at 2:24 PM, Bill Unruh wrote: > > > William G. Unruh __| Canadian Institute for| Tel: +1(604)822-3273 > Physics&Astronomy _|___ Advanced Research _| Fax: +1(604)822-5324 > UBC, Vancouver,BC _|_ Program in Cosmology | un...@physics.ubc.ca > Canada V6T 1Z1 | and Gravity __|_ www.theory.physics.ubc.ca/ > > On Fri, 12 Aug 2016, Chris Greenman wrote: > > I CAN hook it up for PPS but it will require cracking open the puck and >> it's not that crucial for my use >> anyway. >> > > Isn't there an output line from the puck which carries the PPS signal? >
Re: [chrony-users] Not getting time from gpsd
Ok I grabbed a sample of the clock statistics. On Fri, Aug 12, 2016 at 2:53 PM, Bill Unruh wrote: > On Fri, 12 Aug 2016, Chris Greenman wrote: > > it's a usb puck. so no. Actually I haven't actually looked but typical >> USB is +5v data+ data- and gnd. As >> far as I know the only place the pps signal is available is inside the >> puck between the GPS module and the usb >> interface. >> > > Well, usb serial immitatiors can also immitate the control lines from a > serial > line. Thus one of the usb packets can be a simlation of the PPS signalalong > the appropriate serial line. But those are likely to have far worse > behaviour than the actual lines. > It might however be better than the data phrases usually coming along the > serial line. > > > > >> like I said I COULD crack it open and run a new cable that included the >> pps line. >> >> On Fri, Aug 12, 2016 at 2:24 PM, Bill Unruh wrote: >> >> >> William G. Unruh __| Canadian Institute for| Tel: >> +1(604)822-3273 >> Physics&Astronomy _|___ Advanced Research _| Fax: >> +1(604)822-5324 >> UBC, Vancouver,BC _|_ Program in Cosmology | >> un...@physics.ubc.ca >> Canada V6T 1Z1 | and Gravity __|_ >> www.theory.physics.ubc.ca/ >> >> On Fri, 12 Aug 2016, Chris Greenman wrote: >> >> I CAN hook it up for PPS but it will require cracking open >> the puck and it's not that >> crucial for my use >> anyway. >> >> >> Isn't there an output line from the puck which carries the PPS >> signal? >> >> >> >> statistics.tgz Description: GNU Zip compressed data
Re: [chrony-users] Not getting time from gpsd
So how would i tell if my GPS does this and if so how do i get it recognized by the kernel and gpsd? On Fri, Aug 12, 2016 at 2:53 PM, Bill Unruh wrote: > On Fri, 12 Aug 2016, Chris Greenman wrote: > > it's a usb puck. so no. Actually I haven't actually looked but typical >> USB is +5v data+ data- and gnd. As >> far as I know the only place the pps signal is available is inside the >> puck between the GPS module and the usb >> interface. >> > > Well, usb serial immitatiors can also immitate the control lines from a > serial > line. Thus one of the usb packets can be a simlation of the PPS signalalong > the appropriate serial line. But those are likely to have far worse > behaviour than the actual lines. > It might however be better than the data phrases usually coming along the > serial line. > > > > >> like I said I COULD crack it open and run a new cable that included the >> pps line. >> >> On Fri, Aug 12, 2016 at 2:24 PM, Bill Unruh wrote: >> >> >> William G. Unruh __| Canadian Institute for| Tel: >> +1(604)822-3273 >> Physics&Astronomy _|___ Advanced Research _| Fax: >> +1(604)822-5324 >> UBC, Vancouver,BC _|_ Program in Cosmology | >> un...@physics.ubc.ca >> Canada V6T 1Z1 | and Gravity __|_ >> www.theory.physics.ubc.ca/ >> >> On Fri, 12 Aug 2016, Chris Greenman wrote: >> >> I CAN hook it up for PPS but it will require cracking open >> the puck and it's not that >> crucial for my use >> anyway. >> >> >> Isn't there an output line from the puck which carries the PPS >> signal? >> >> >> >>
Re: [chrony-users] Not getting time from gpsd
No. We're just fine tuning the refclock line in chrony.conf. I don't really experience huge jumps. It might fall behind during a reboot because the pi doesn't have an RTC but rather it saves time on shutdown and restores on boot. Really my only goal is to have somewhat accurate (less than a second) time whether I have internet or not. We've already achieved this, now it's just a matter of making sure GPS doesn't clobber ntp and vice versa. On Aug 14, 2016 7:24 PM, "Bill Unruh" wrote: > Is this supposed to be at a time when your system suddenly looses track of > the > time and jumps by hours or days? I see nothing in the gps signal that > indicates anything like that. > > If it is supposed to be at the begining of this sample, please give a > sample > which spans across, not begins at, one of those weirdnesses. > > Note also that probably a copy of the measurements and the refclock logs > ove > onw of those times might be more illuminating. Statistics is rather > processed > already. > > > > > > > William G. Unruh __| Canadian Institute for| Tel: +1(604)822-3273 > Physics&Astronomy _|___ Advanced Research _| Fax: +1(604)822-5324 > UBC, Vancouver,BC _|_ Program in Cosmology | un...@physics.ubc.ca > Canada V6T 1Z1 | and Gravity __|_ www.theory.physics.ubc.ca/ > > On Sun, 14 Aug 2016, Chris Greenman wrote: > > Ok I grabbed a sample of the clock statistics. >> >> >> On Fri, Aug 12, 2016 at 2:53 PM, Bill Unruh wrote: >> On Fri, 12 Aug 2016, Chris Greenman wrote: >> >> it's a usb puck. so no. Actually I haven't actually looked >> but >> typical USB is +5v data+ data- and gnd. As >> far as I know the only place the pps signal is available is >> inside the >> puck between the GPS module and the usb >> interface. >> >> >> Well, usb serial immitatiors can also immitate the control lines >> from a serial >> line. Thus one of the usb packets can be a simlation of the PPS >> signalalong >> the appropriate serial line. But those are likely to have far >> worse behaviour >> than the actual lines. >> It might however be better than the data phrases usually coming >> along the >> serial line. >> >> >> >> like I said I COULD crack it open and run a new cable that >> included >> the pps line. >> >> On Fri, Aug 12, 2016 at 2:24 PM, Bill Unruh < >> un...@physics.ubc.ca> >> wrote: >> >> >> William G. Unruh __| Canadian Institute for| Tel: >> +1(604)822-3273 >> Physics&Astronomy _|___ Advanced Research _| Fax: >> +1(604)822-5324 >> UBC, Vancouver,BC _|_ Program in Cosmology | >> un...@physics.ubc.ca >> Canada V6T 1Z1 | and Gravity __|_ >> www.theory.physics.ubc.ca/ >> >> On Fri, 12 Aug 2016, Chris Greenman wrote: >> >> I CAN hook it up for PPS but it will require >> cracking open >> the puck and it's not that >> crucial for my use >> anyway. >> >> >> Isn't there an output line from the puck which carries >> the PPS >> signal? >> >> >> >> >> >>
Re: [chrony-users] Not getting time from gpsd
Done. running some more statistics. On Mon, Aug 15, 2016 at 4:04 AM, Miroslav Lichvar wrote: > On Sun, Aug 14, 2016 at 05:54:08PM -0400, Chris Greenman wrote: > > Ok I grabbed a sample of the clock statistics. > > The statistics log shows that the offset of the GPS refclock relative > to the NTP server is about 20 +/- 10 milliseconds. So you should > increase the offset value in the refclock line by 0.02 to get the > mean offset close to zero. When the NTP source is offline, your clock > synchronized to the GPS source should be accurate to about 10 > milliseconds. > > -- > Miroslav Lichvar > > -- > To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org > with "unsubscribe" in the subject. > For help email chrony-users-requ...@chrony.tuxfamily.org > with "help" in the subject. > Trouble? Email listmas...@chrony.tuxfamily.org. > >
Re: [chrony-users] Not getting time from gpsd
Finally got a chance to grab more stats.my refclock line now looks like this: refclock SHM 0 refid GPS offset 0.060 delay 0.22 minsamples 64 I'm attaching the latest stats. On Mon, Aug 15, 2016 at 10:18 AM, Bill Unruh wrote: > On Mon, 15 Aug 2016, Chris Greenman wrote: > > >> No. We're just fine tuning the refclock line in chrony.conf. I don't >> really >> experience huge jumps. It might fall behind during a reboot because the >> pi doesn't >> have an RTC but rather it saves time on shutdown and restores on boot. >> > > Ah sorry. they yes, during that time period gps settled down to being out > about 10ms > which is well within your requirements. Unrotunately, nmea is not the most > stable of references. Thus if for some reason your gps puck becomes busy > for > some reason, (moving the computer, something happens with the gps > constellation,...) that offset could change, but certainly not by a second. > The handling of leap seconds by your puck could be an issue. Not sure how > it > handles that. But at worst it would mean that some midnight (UTC) at the > end > of Dec or Jun, the clock would suddenly be out by a second, and would > slowly > (well not that slowly with chrony) drift its way back into sync. > > > > >> >> Really my only goal is to have somewhat accurate (less than a second) >> time whether I >> have internet or not. We've already achieved this, now it's just a >> matter of >> making sure GPS doesn't clobber ntp and vice versa. >> > > Not sure what you mean by "ntp". > >> >> >> >> On Aug 14, 2016 7:24 PM, "Bill Unruh" wrote: >> Is this supposed to be at a time when your system suddenly looses >> track >> of the >> time and jumps by hours or days? I see nothing in the gps signal >> that >> indicates anything like that. >> >> If it is supposed to be at the begining of this sample, please give >> a >> sample >> which spans across, not begins at, one of those weirdnesses. >> >> Note also that probably a copy of the measurements and the refclock >> logs >> ove >> onw of those times might be more illuminating. Statistics is rather >> processed >> already. >> >> >> >> >> >> >> William G. Unruh __| Canadian Institute for| Tel: >> +1(604)822-3273 >> Physics&Astronomy _|___ Advanced Research _| Fax: >> +1(604)822-5324 >> UBC, Vancouver,BC _|_ Program in Cosmology | >> un...@physics.ubc.ca >> Canada V6T 1Z1 | and Gravity __|_ >> www.theory.physics.ubc.ca/ >> >> On Sun, 14 Aug 2016, Chris Greenman wrote: >> >> Ok I grabbed a sample of the clock statistics. >> >> >> On Fri, Aug 12, 2016 at 2:53 PM, Bill Unruh >> wrote: >> On Fri, 12 Aug 2016, Chris Greenman wrote: >> >> it's a usb puck. so no. Actually I haven't >> actually looked but >> typical USB is +5v data+ data- and gnd. As >> far as I know the only place the pps signal is >> available is inside the >> puck between the GPS module and the usb >> interface. >> >> >> Well, usb serial immitatiors can also immitate the >> control lines from a serial >> line. Thus one of the usb packets can be a simlation >> of the PPS signalalong >> the appropriate serial line. But those are likely to >> have far worse behaviour >> than the actual lines. >> It might however be better than the data phrases >> usually coming along the >> serial line. >> >> >> >> like I said I COULD crack it open and run a new >> cable that included >> the pps line. >> >> On Fri, Aug 12, 2016 at 2:24 PM, Bill Unruh >> >> wrote: >> >> >> William G. Unruh __| Canadian Institute >> for| Tel: >> +1(604)822-3273 >> Physics&Astronomy _|___ Advanced Research >
[chrony-users] Not getting time from gpsd
Hello, I'm having an issue with getting time from gpsd. My setup is: Raspberry Pi 3 running Jessie Lite USB U-Blox gps gpsd is receiving NMEA from the GPS, cgps also shows time and position properly. My chrony.conf is: server 0.us.pool.ntp.org server 1.us.pool.ntp.org server 2.us.pool.ntp.org server 3.us.pool.ntp.org driftfile /var/lib/chrony/drift allow refclock SHM 0 refid GPS precision 1e-1 offset 0. delay 0.2 makestep 1 -1 Chronyc sources shows this: $ chronyc sources 210 Number of sources = 5 MS Name/IP address Stratum Poll Reach LastRx Last sample === #? GPS 0 4 0 10y +0ns[ +0ns] +/- 0ns ^+ time-c.nist.gov 1 9 375 110-23ms[ -22ms] +/- 47ms ^* pool-96-248-122-64.cmdnnj 1 10 37756 +9749us[ +11ms] +/- 18ms ^- 104.156.99.2262 9 377 367+15ms[ +17ms] +/- 107ms ^- 4.53.160.75 This system is going to be used on a boat and might not have internet. I can tell that both programs are accessing the shared memory using ipcs -m: -- Shared Memory Segments keyshmid owner perms bytes nattch status 0x4e545030 0 root 60080 2 0x4e545031 32769 root 60080 1 Any idea why chrony isn't getting time from the GPS? Thanks
Re: [chrony-users] Not getting time from gpsd
Same thing. Already tried it. On Aug 6, 2016 6:35 AM, "Steve Horton" wrote: > I'd look closer at the SOCK option under the refclock section. > https://chrony.tuxfamily.org/manual.html#refclock-directive > > On Aug 6, 2016 12:00 AM, "Chris Greenman" > wrote: > > > > Hello, > > I'm having an issue with getting time from gpsd. > > > > My setup is: > > Raspberry Pi 3 running Jessie Lite > > USB U-Blox gps > > > > gpsd is receiving NMEA from the GPS, cgps also shows time and position > properly. > > > > My chrony.conf is: > >> > >> server 0.us.pool.ntp.org > >> server 1.us.pool.ntp.org > >> server 2.us.pool.ntp.org > >> server 3.us.pool.ntp.org > >> driftfile /var/lib/chrony/drift > >> allow > >> refclock SHM 0 refid GPS precision 1e-1 offset 0. delay 0.2 > >> makestep 1 -1 > >> > > Chronyc sources shows this: > >> > >> $ chronyc sources > >> 210 Number of sources = 5 > >> MS Name/IP address Stratum Poll Reach LastRx Last sample > >> > === > >> #? GPS 0 4 0 10y +0ns[ +0ns] > +/-0ns > >> ^+ time-c.nist.gov 1 9 375 110-23ms[ -22ms] > +/- 47ms > >> ^* pool-96-248-122-64.cmdnnj 1 10 37756 +9749us[ +11ms] > +/- 18ms > >> ^- 104.156.99.2262 9 377 367+15ms[ +17ms] > +/- 107ms > >> ^- 4.53.160.75 > >> > > This system is going to be used on a boat and might not have internet. > I can tell that both programs are accessing the shared memory using ipcs -m: > > > >> -- Shared Memory Segments > >> keyshmid owner perms bytes nattch > status > >> 0x4e545030 0 root 60080 2 > > >> 0x4e545031 32769 root 60080 1 > >> > > Any idea why chrony isn't getting time from the GPS? > > > > Thanks >
Re: [chrony-users] Not getting time from gpsd
Nothing in /dev/shm. I added the log entries to chrony.conf but there is no /var/log/chrony/refclocks file. here is the latest 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 driftfile /var/lib/chrony/drift allow # set larger delay to allow the NMEA source to overlap with # the other sources and avoid the falseticker status refclock SHM 0 refid GPS precision 1e-1 offset 0. delay 0.2 #refclock SHM 1 refid PPS precision 1e-9 refclock SOCK /var/run/chrony.ttyACM0.sock refid GPSS makestep 1 -1 logdir /var/log/chrony log refclocks after making the mods I restarted chrony. here is the chronyc sources output 210 Number of sources = 2 MS Name/IP address Stratum Poll Reach LastRx Last sample === #? GPS 0 4 0 10y +0ns[ +0ns] +/- 0ns #? GPSS 0 4 0 10y +0ns[ +0ns] +/- 0ns ps -ef |grep gpsd |grep -v grep gpsd 31426 1 0 13:36 ?00:00:00 /usr/sbin/gpsd -N -F /var/run/chrony.ttyACM0.sock /dev/ttyACM0 On Sat, Aug 6, 2016 at 11:48 AM, Steve Horton wrote: > Agreed. Shms live in /dev along with the real time clocks /dev/rtc0. Your > kernel config dictates what's there. Look around in dev and see what shms > are there and mod your chrony configuration to point to one of them and > check tracking. I'd also comment out all server lines until you get it > syncing with the GPS device. > > On Aug 6, 2016 11:18 AM, "Bill Unruh" wrote: > >> shm should also work. Question is if they are reading the same shm >> location. >> >> >> >> >> William G. Unruh __| Canadian Institute for| Tel: +1(604)822-3273 >> Physics&Astronomy _|___ Advanced Research _| Fax: +1(604)822-5324 >> UBC, Vancouver,BC _|_ Program in Cosmology | un...@physics.ubc.ca >> Canada V6T 1Z1 | and Gravity __|_ www.theory.physics.ubc.ca/ >> >> On Sat, 6 Aug 2016, Steve Horton wrote: >> >> >>> Not really Chris. I don't see a sock option in your configuration file. >>> Gpsd should write time out to a device >>> file some where and chrony can read the time from that device file via a >>> Unix domain socket. Like I said..look >>> into the sock option and how it relates to gpsd. >>> >>> >>> On Aug 6, 2016 10:10 AM, "Chris Greenman" >>> wrote: >>> >>> Same thing. Already tried it. >>> >>> >>> On Aug 6, 2016 6:35 AM, "Steve Horton" >>> wrote: >>> >>> I'd look closer at the SOCK option under the refclock >>> section. >>> https://chrony.tuxfamily.org/manual.html#refclock-directive >>> >>> On Aug 6, 2016 12:00 AM, "Chris Greenman" < >>> chris.m.green...@gmail.com> wrote: >>> > >>> > Hello, >>> > I'm having an issue with getting time from gpsd. >>> > >>> > My setup is: >>> > Raspberry Pi 3 running Jessie Lite >>> > USB U-Blox gps >>> > >>> > gpsd is receiving NMEA from the GPS, cgps also shows time >>> and position properly. >>> > >>> > My chrony.conf is: >>> >> >>> >> server 0.us.pool.ntp.org >>> >> server 1.us.pool.ntp.org >>> >> server 2.us.pool.ntp.org >>> >> server 3.us.pool.ntp.org >>> >> driftfile /var/lib/chrony/drift >>> >> allow >>> >> refclock SHM 0 refid GPS precision 1e-1 offset 0. >>> delay 0.2 >>> >> makestep 1 -1 >>> >> >>> > Chronyc sources shows this: >>> >> >>> >> $ chronyc sources >>> >> 210 Number of sources = 5 >>> >> MS Name/IP address Stratum Poll Reach LastRx Last >>> sample >>> >> == >>> = >>> >> #? GPS 0 4 0 10y >>> +0ns[ +0ns] +/-0ns >>> >> ^+ time-c.nist.gov 1 9 375 110 >>> -23ms[ -22ms] +/- 47ms
Re: [chrony-users] Not getting time from gpsd
I only included the relevant lines. When the socket didn't work either I commented it out and went back to shm Here is my full chrony.conf. Note, I commented out the ntp servers so that I can just concentrate on troubleshooting the GPS clock and uncommented the SOCK line #server 0.us.pool.ntp.org #server 1.us.pool.ntp.org #server 2.us.pool.ntp.org #server 3.us.pool.ntp.org driftfile /var/lib/chrony/drift allow # set larger delay to allow the NMEA source to overlap with # the other sources and avoid the falseticker status refclock SHM 0 refid GPS precision 1e-1 offset 0. delay 0.2 #refclock SHM 1 refid PPS precision 1e-9 refclock SOCK /var/run/chrony.ttyACM0.sock refid GPSS makestep 1 -1 On Sat, Aug 6, 2016 at 10:41 AM, Steve Horton wrote: > Not really Chris. I don't see a sock option in your configuration file. > Gpsd should write time out to a device file some where and chrony can read > the time from that device file via a Unix domain socket. Like I said..look > into the sock option and how it relates to gpsd. > > On Aug 6, 2016 10:10 AM, "Chris Greenman" > wrote: > >> Same thing. Already tried it. >> >> On Aug 6, 2016 6:35 AM, "Steve Horton" wrote: >> >>> I'd look closer at the SOCK option under the refclock section. >>> https://chrony.tuxfamily.org/manual.html#refclock-directive >>> >>> On Aug 6, 2016 12:00 AM, "Chris Greenman" >>> wrote: >>> > >>> > Hello, >>> > I'm having an issue with getting time from gpsd. >>> > >>> > My setup is: >>> > Raspberry Pi 3 running Jessie Lite >>> > USB U-Blox gps >>> > >>> > gpsd is receiving NMEA from the GPS, cgps also shows time and position >>> properly. >>> > >>> > My chrony.conf is: >>> >> >>> >> server 0.us.pool.ntp.org >>> >> server 1.us.pool.ntp.org >>> >> server 2.us.pool.ntp.org >>> >> server 3.us.pool.ntp.org >>> >> driftfile /var/lib/chrony/drift >>> >> allow >>> >> refclock SHM 0 refid GPS precision 1e-1 offset 0. delay 0.2 >>> >> makestep 1 -1 >>> >> >>> > Chronyc sources shows this: >>> >> >>> >> $ chronyc sources >>> >> 210 Number of sources = 5 >>> >> MS Name/IP address Stratum Poll Reach LastRx Last sample >>> >> >>> === >>> >> #? GPS 0 4 0 10y +0ns[ +0ns] >>> +/-0ns >>> >> ^+ time-c.nist.gov 1 9 375 110-23ms[ -22ms] >>> +/- 47ms >>> >> ^* pool-96-248-122-64.cmdnnj 1 10 37756 +9749us[ +11ms] >>> +/- 18ms >>> >> ^- 104.156.99.2262 9 377 367+15ms[ +17ms] >>> +/- 107ms >>> >> ^- 4.53.160.75 >>> >> >>> > This system is going to be used on a boat and might not have >>> internet. I can tell that both programs are accessing the shared memory >>> using ipcs -m: >>> > >>> >> -- Shared Memory Segments >>> >> keyshmid owner perms bytes nattch >>> status >>> >> 0x4e545030 0 root 60080 2 >>> >>> >> 0x4e545031 32769 root 60080 1 >>> >> >>> > Any idea why chrony isn't getting time from the GPS? >>> > >>> > Thanks >>> >>
Re: [chrony-users] Not getting time from gpsd
No gpsd.conf. /etc/default/gpsd is : # Default settings for the gpsd init script and the hotplug wrapper. # Start the gpsd daemon automatically at boot time START_DAEMON="true" # Use USB hotplugging to add new USB devices automatically to the daemon USBAUTO="true" # Devices gpsd should collect to at boot time. # They need to be read/writeable, either by user gpsd or the group dialout. DEVICES="/dev/ttyACM0" # Other options you want to pass to gpsd GPSD_OPTIONS="-F /var/run/chrony.ttyACM0.sock" $ ps -ef |grep gpsd |grep -v grep gpsd 31426 1 0 13:36 ?00:00:00 /usr/sbin/gpsd -N -F /var/run/chrony.ttyACM0.sock /dev/ttyACM0 cgps shows 3d fix On Sat, Aug 6, 2016 at 2:11 PM, Steve Horton wrote: > Ok..can I see your gpsd conf? > > On Aug 6, 2016 1:39 PM, "Chris Greenman" > wrote: > >> I only included the relevant lines. When the socket didn't work either I >> commented it out and went back to shm >> >> Here is my full chrony.conf. Note, I commented out the ntp servers so >> that I can just concentrate on troubleshooting the GPS clock and >> uncommented the SOCK line >> >> >> #server 0.us.pool.ntp.org >> #server 1.us.pool.ntp.org >> #server 2.us.pool.ntp.org >> #server 3.us.pool.ntp.org >> >> driftfile /var/lib/chrony/drift >> >> allow >> >> # set larger delay to allow the NMEA source to overlap with >> # the other sources and avoid the falseticker status >> refclock SHM 0 refid GPS precision 1e-1 offset 0. delay 0.2 >> #refclock SHM 1 refid PPS precision 1e-9 >> refclock SOCK /var/run/chrony.ttyACM0.sock refid GPSS >> >> makestep 1 -1 >> >> >> >> >> On Sat, Aug 6, 2016 at 10:41 AM, Steve Horton >> wrote: >> >>> Not really Chris. I don't see a sock option in your configuration file. >>> Gpsd should write time out to a device file some where and chrony can read >>> the time from that device file via a Unix domain socket. Like I said..look >>> into the sock option and how it relates to gpsd. >>> >>> On Aug 6, 2016 10:10 AM, "Chris Greenman" >>> wrote: >>> >>>> Same thing. Already tried it. >>>> >>>> On Aug 6, 2016 6:35 AM, "Steve Horton" wrote: >>>> >>>>> I'd look closer at the SOCK option under the refclock section. >>>>> https://chrony.tuxfamily.org/manual.html#refclock-directive >>>>> >>>>> On Aug 6, 2016 12:00 AM, "Chris Greenman" >>>>> wrote: >>>>> > >>>>> > Hello, >>>>> > I'm having an issue with getting time from gpsd. >>>>> > >>>>> > My setup is: >>>>> > Raspberry Pi 3 running Jessie Lite >>>>> > USB U-Blox gps >>>>> > >>>>> > gpsd is receiving NMEA from the GPS, cgps also shows time and >>>>> position properly. >>>>> > >>>>> > My chrony.conf is: >>>>> >> >>>>> >> server 0.us.pool.ntp.org >>>>> >> server 1.us.pool.ntp.org >>>>> >> server 2.us.pool.ntp.org >>>>> >> server 3.us.pool.ntp.org >>>>> >> driftfile /var/lib/chrony/drift >>>>> >> allow >>>>> >> refclock SHM 0 refid GPS precision 1e-1 offset 0. delay 0.2 >>>>> >> makestep 1 -1 >>>>> >> >>>>> > Chronyc sources shows this: >>>>> >> >>>>> >> $ chronyc sources >>>>> >> 210 Number of sources = 5 >>>>> >> MS Name/IP address Stratum Poll Reach LastRx Last sample >>>>> >> >>>>> === >>>>> >> #? GPS 0 4 0 10y +0ns[ >>>>> +0ns] +/-0ns >>>>> >> ^+ time-c.nist.gov 1 9 375 110-23ms[ >>>>> -22ms] +/- 47ms >>>>> >> ^* pool-96-248-122-64.cmdnnj 1 10 37756 +9749us[ >>>>> +11ms] +/- 18ms >>>>> >> ^- 104.156.99.2262 9 377 367+15ms[ >>>>> +17ms] +/- 107ms >>>>> >> ^- 4.53.160.75 >>>>> >> >>>>> > This system is going to be used on a boat and might not have >>>>> internet. I can tell that both programs are accessing the shared memory >>>>> using ipcs -m: >>>>> > >>>>> >> -- Shared Memory Segments >>>>> >> keyshmid owner perms bytes nattch >>>>> status >>>>> >> 0x4e545030 0 root 60080 2 >>>>> >>>>> >> 0x4e545031 32769 root 60080 1 >>>>> >> >>>>> > Any idea why chrony isn't getting time from the GPS? >>>>> > >>>>> > Thanks >>>>> >>>> >>
Re: [chrony-users] Not getting time from gpsd
$ file /var/run/chrony.ttyACM0.sock
/var/run/chrony.ttyACM0.sock: socket
cat /etc/init.d/gpsd
$ cat /etc/init.d/gpsd
#!/bin/sh
### BEGIN INIT INFO
# Provides: gpsd
# Required-Start:$remote_fs $syslog $network
# Should-Start: bluetooth dbus udev
# Required-Stop: $remote_fs $syslog $network
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# X-Start-Before:ntp
# Short-Description: GPS (Global Positioning System) daemon
# Description: The gpsd service daemon is able to monitor one or
#more GPS devices connected to a host computer, making
#all data on the location and movements of the sensors
#available to be queried on TCP port 2947.
### END INIT INFO
# Author: Bernd Zeimetz
#
# Please remove the "Author" lines above and replace them
# with your own name if you copy and modify this script.
# Do NOT "set -e"
# PATH should only include /usr/* if it runs after the mountnfs.sh script
RUNDIR=/run/gpsd
PATH=/sbin:/usr/sbin:/bin:/usr/bin
DESC="GPS (Global Positioning System) daemon"
NAME=gpsd
DAEMON=/usr/sbin/$NAME
PIDFILE=$RUNDIR/$NAME.pid
SCRIPTNAME=/etc/init.d/$NAME
# Exit if the package is not installed
[ -x "$DAEMON" ] || exit 0
# Read configuration variable file if it is present
[ -r /etc/default/$NAME ] && . /etc/default/$NAME
if [ -z "$GPSD_SOCKET" ] && [ -z "$DEVICES" ]; then
GPSD_SOCKET=/var/run/gpsd.sock
fi
if [ -n "$GPSD_SOCKET" ]; then
GPSD_OPTIONS="$GPSD_OPTIONS -F $GPSD_SOCKET"
fi
# Load the VERBOSE setting and other rcS variables
. /lib/init/vars.sh
# Define LSB log_* functions.
# Depend on lsb-base (>= 3.0-6) to ensure that this file is present.
. /lib/lsb/init-functions
#
# Function that starts the daemon/service
#
do_start()
{
# Return
# 0 if daemon has been started
# 1 if daemon was already running
# 2 if daemon could not be started
mkdir -p $RUNDIR || return 2
start-stop-daemon --start --quiet --pidfile $PIDFILE --exec $DAEMON --test
> /dev/null \
|| return 1
start-stop-daemon --start --quiet --pidfile $PIDFILE --exec $DAEMON -- \
$GPSD_OPTIONS -P $PIDFILE $DEVICES \
|| return 2
}
#
# Function that stops the daemon/service
#
do_stop()
{
# Return
# 0 if daemon has been stopped
# 1 if daemon was already stopped
# 2 if daemon could not be stopped
# other if a failure occurred
start-stop-daemon --stop --quiet --retry=TERM/30/KILL/5 --pidfile $PIDFILE
--name $NAME
RETVAL="$?"
[ "$RETVAL" = 2 ] && return 2
# Many daemons don't delete their pidfiles when they exit.
rm -f $PIDFILE
return "$RETVAL"
}
#
# Function that sends a SIGHUP to the daemon/service
#
do_reload() {
#
# If the daemon can reload its configuration without
# restarting (for example, when it is sent a SIGHUP),
# then implement that here.
#
start-stop-daemon --stop --signal 1 --quiet --pidfile $PIDFILE --name $NAME
return 0
}
case "$1" in
start)
if [ "$START_DAEMON" = "true" ]; then
[ "$VERBOSE" != no ] && log_daemon_msg "Starting $DESC" "$NAME"
do_start
case "$?" in
0|1) [ "$VERBOSE" != no ] && log_end_msg 0 ;;
2) [ "$VERBOSE" != no ] && log_end_msg 1 ;;
esac
else
[ "$VERBOSE" != no ] && \
log_daemon_msg "Not starting $DESC" "$NAME" && \
log_end_msg 0
fi
;;
stop)
[ "$VERBOSE" != no ] && log_daemon_msg "Stopping $DESC" "$NAME"
do_stop
case "$?" in
0|1) [ "$VERBOSE" != no ] && log_end_msg 0 ;;
2) [ "$VERBOSE" != no ] && log_end_msg 1 ;;
esac
;;
status)
status_of_proc "$DAEMON" "$NAME" && exit 0 || exit $?
;;
reload|force-reload)
log_daemon_msg "Reloading $DESC" "$NAME"
do_reload
log_end_msg $?
;;
restart)
#
# If the "reload" option is implemented then remove the
# 'force-reload' alias
#
log_daemon_msg "Restarting $DESC" "$NAME"
do_stop
case "$?" in
0|1)
do_start
case "$?" in
0) log_end_msg 0 ;;
1) log_end_msg 1 ;; # Old process is still running
*) log_end_msg 1 ;; # Failed to start
esac
;;
*)
# Failed to stop
log_end_msg 1
;;
esac
;;
*)
echo "Usage: $SCRIPTNAME {start|stop|status|restart|force-reload}" >&2
exit 3
;;
esac
:
On Sat, Aug 6, 2016 at 11:08 PM, Steve Horton
wrote:
> Sorry..i meant your start script. So do you start gpsd after chrony is
> allready running and the sock created? Does it get built correctly? Can you
> do a file on it?
>
> On Aug 6, 2016 10:29 PM, "Chris Greenman"
> wrote:
>
>> No gpsd.conf. /etc/default/gpsd is :
>>
>> # Default settings for the gpsd init script and the hotplu
Re: [chrony-users] Not getting time from gpsd
I've attached the strace files. The commands I used were:
root@IrishMistII:/tmp# strace -o /tmp/chrony.strace.out chronyd
root@IrishMistII:/tmp# strace -o /tmp/gpsd.strace.out gpsd -D 8 -F
/var/run/chrony.ttyACM0.sock /dev/ttyACM0
On Aug 7, 2016 12:50 AM, "Steve Horton" wrote:
> We need to see if gpsd is sending and if chrony is rx anything on that
> socket. I'd start both process in strace to srart. Then maybe start gpsd in
> debug -D 8 and see if its writing to that chrony socket. Strace will show
> what's happening underneath.
>
> On Aug 6, 2016 11:37 PM, "Chris Greenman"
> wrote:
>
>> $ file /var/run/chrony.ttyACM0.sock
>> /var/run/chrony.ttyACM0.sock: socket
>>
>> cat /etc/init.d/gpsd
>>
>> $ cat /etc/init.d/gpsd
>> #!/bin/sh
>> ### BEGIN INIT INFO
>> # Provides: gpsd
>> # Required-Start:$remote_fs $syslog $network
>> # Should-Start: bluetooth dbus udev
>> # Required-Stop: $remote_fs $syslog $network
>> # Default-Start: 2 3 4 5
>> # Default-Stop: 0 1 6
>> # X-Start-Before:ntp
>> # Short-Description: GPS (Global Positioning System) daemon
>> # Description: The gpsd service daemon is able to monitor one or
>> #more GPS devices connected to a host computer, making
>> #all data on the location and movements of the sensors
>> #available to be queried on TCP port 2947.
>> ### END INIT INFO
>>
>> # Author: Bernd Zeimetz
>> #
>> # Please remove the "Author" lines above and replace them
>> # with your own name if you copy and modify this script.
>>
>> # Do NOT "set -e"
>>
>> # PATH should only include /usr/* if it runs after the mountnfs.sh script
>> RUNDIR=/run/gpsd
>> PATH=/sbin:/usr/sbin:/bin:/usr/bin
>> DESC="GPS (Global Positioning System) daemon"
>> NAME=gpsd
>> DAEMON=/usr/sbin/$NAME
>> PIDFILE=$RUNDIR/$NAME.pid
>> SCRIPTNAME=/etc/init.d/$NAME
>>
>> # Exit if the package is not installed
>> [ -x "$DAEMON" ] || exit 0
>>
>> # Read configuration variable file if it is present
>> [ -r /etc/default/$NAME ] && . /etc/default/$NAME
>>
>> if [ -z "$GPSD_SOCKET" ] && [ -z "$DEVICES" ]; then
>> GPSD_SOCKET=/var/run/gpsd.sock
>> fi
>>
>> if [ -n "$GPSD_SOCKET" ]; then
>> GPSD_OPTIONS="$GPSD_OPTIONS -F $GPSD_SOCKET"
>> fi
>>
>> # Load the VERBOSE setting and other rcS variables
>> . /lib/init/vars.sh
>>
>> # Define LSB log_* functions.
>> # Depend on lsb-base (>= 3.0-6) to ensure that this file is present.
>> . /lib/lsb/init-functions
>>
>> #
>> # Function that starts the daemon/service
>> #
>> do_start()
>> {
>> # Return
>> # 0 if daemon has been started
>> # 1 if daemon was already running
>> # 2 if daemon could not be started
>>
>> mkdir -p $RUNDIR || return 2
>>
>> start-stop-daemon --start --quiet --pidfile $PIDFILE --exec $DAEMON
>> --test > /dev/null \
>> || return 1
>> start-stop-daemon --start --quiet --pidfile $PIDFILE --exec $DAEMON -- \
>> $GPSD_OPTIONS -P $PIDFILE $DEVICES \
>> || return 2
>> }
>>
>> #
>> # Function that stops the daemon/service
>> #
>> do_stop()
>> {
>> # Return
>> # 0 if daemon has been stopped
>> # 1 if daemon was already stopped
>> # 2 if daemon could not be stopped
>> # other if a failure occurred
>> start-stop-daemon --stop --quiet --retry=TERM/30/KILL/5 --pidfile
>> $PIDFILE --name $NAME
>> RETVAL="$?"
>> [ "$RETVAL" = 2 ] && return 2
>> # Many daemons don't delete their pidfiles when they exit.
>> rm -f $PIDFILE
>> return "$RETVAL"
>> }
>>
>> #
>> # Function that sends a SIGHUP to the daemon/service
>> #
>> do_reload() {
>> #
>> # If the daemon can reload its configuration without
>> # restarting (for example, when it is sent a SIGHUP),
>> # then implement that here.
>> #
>> start-stop-daemon --stop --signal 1 --quiet --pidfile $PIDFILE --name
>> $NAME
>> return 0
>> }
>>
>> case "$1" in
>> start)
>> if [ "$START_DAEMON" = "true" ]; then
>> [ "$VERBOSE" != no ] && log_daemon_msg "Starting $DESC" "$NAME"
>> do_start
>> case "$?" in
>> 0|1) [ &quo
Re: [chrony-users] Not getting time from gpsd
I didn't think the -F option was correct but it didn't seem to work without it either. I was just hunting and pecking. My gps does not (directly) provide PPS. It's a ublox 6 so I could probably wire it in but to be honest, I don't need that much precision. For my needs NTP is accurate enough but it's not always available which is why I want time from GPS. As for the dependencies and starting order, that's easy to fix. Right now gpsd is starting from init.d and chrony is starting from systemd. I can just remove the rc#.d links and write a new .service file for gpsd with "After = chrony.service" and "Wanted by = default.target". Then verify the chrony service file jives with the one for gpsd. The last gps strace I posted was with the -D 8 option specified. I did not, however, specify -f to strace so it is not following after it forks. As soon as I get some play time today I'll run some new traces. Is attaching the best way to send the files or is there a bit bucket somewhere I should use? On Aug 8, 2016 4:24 AM, "Miroslav Lichvar" wrote: > On Sun, Aug 07, 2016 at 10:27:02PM -0400, Chris Greenman wrote: > > I've attached the strace files. The commands I used were: > > > > root@IrishMistII:/tmp# strace -o /tmp/chrony.strace.out chronyd > > root@IrishMistII:/tmp# strace -o /tmp/gpsd.strace.out gpsd -D 8 -F > > /var/run/chrony.ttyACM0.sock /dev/ttyACM0 > > The -F option of gpsd is for its control socket. It's not related to > the chrony socket. Also, I think gpsd uses the chrony socket only for > samples based on PPS signal, so if you don't have working PPS, you'll > probably need to stick with SHM. > > The problem is most likely one of the following: > 1) gpsd is not writing to SHM > 2) chronyd is not reading from SMH > 3) chronyd is ignoring SHM samples (e.g. when the receive timestamp is >from future) > > Output from "gpsd -D 8" should confirm it's not 1). For 2) and 3) it > would be best to see "chronyd -d -d" output, but this will work only > if chronyd was compiled with debugging support (configure has > --enable-debug option since chrony-1.30). > > Recent gpsd releases include a ntpshmmon tool, which can print changes > in the SHM segment and could be useful to reject 1) and 2). > > -- > Miroslav Lichvar > > -- > To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org > with "unsubscribe" in the subject. > For help email chrony-users-requ...@chrony.tuxfamily.org > with "help" in the subject. > Trouble? Email listmas...@chrony.tuxfamily.org. > >
Re: [chrony-users] Not getting time from gpsd
Ok, Here are the latest strace files. It looks like the chrony in the Jessie repos does not have debug compiled in. I downloaded the latest source and compiled. The trace is using that binary not the distro supplied (Ver. 1.30). I should note that I already tried the fresh compiled version before and got the same results as the distro version. On Mon, Aug 8, 2016 at 9:19 AM, Miroslav Lichvar wrote: > On Mon, Aug 08, 2016 at 09:05:03AM -0400, Chris Greenman wrote: > > I didn't think the -F option was correct but it didn't seem to work > without > > it either. I was just hunting and pecking. My gps does not (directly) > > provide PPS. It's a ublox 6 so I could probably wire it in but to be > > honest, I don't need that much precision. For my needs NTP is accurate > > enough but it's not always available which is why I want time from GPS. > > Note that GPS without PPS is typically less stable than NTP over > internet. Binary mode may work better than NMEA. > > > As > > for the dependencies and starting order, that's easy to fix. Right now > > gpsd is starting from init.d and chrony is starting from systemd. I can > > just remove the rc#.d links and write a new .service file for gpsd with > > "After = chrony.service" and "Wanted by = default.target". Then verify > the > > chrony service file jives with the one for gpsd. > > With SHM refclock that shouldn't be necessary. Only for SOCK chronyd > needs to be started first. > > > The last gps strace I posted was with the -D 8 option specified. I did > > not, however, specify -f to strace so it is not following after it forks. > > The -N option disables forking. Another useful option is -n, which > tells gpsd to not wait for clients, so SHM is always updated. > > > As soon as I get some play time today I'll run some new traces. Is > > attaching the best way to send the files or is there a bit bucket > somewhere > > I should use? > > I think it's ok to post here if it's not too large (e.g. > 100KB). Or > you can compress it first. > > -- > Miroslav Lichvar > > -- > To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org > with "unsubscribe" in the subject. > For help email chrony-users-requ...@chrony.tuxfamily.org > with "help" in the subject. > Trouble? Email listmas...@chrony.tuxfamily.org. > > straces.tgz Description: GNU Zip compressed data
Re: [chrony-users] Not getting time from gpsd
UGH!!!I really wish distros would provide software that is more up to date.Looks like it might have been gpsd. On a whim I decided to scrap the repo provided gpsd AND chrony and compiled everything myself. it now appears as if everything is working. chrony sources output: 210 Number of sources = 1 MS Name/IP address Stratum Poll Reach LastRx Last sample === #* GPS 0 4 37717 +296us[ +347us] +/- 200ms I am perfectly happy with 200ms error in time. That more than suits my needs. Sorry for wasting everyone's time.I was trying to save time and frustration by using the repo supplied (and you would think tested) binaries. It would have been a lot quicker and less frustrating to just compile. lol. On Mon, Aug 8, 2016 at 11:50 AM, Chris Greenman wrote: > Ok, Here are the latest strace files. It looks like the chrony in the > Jessie repos does not have debug compiled in. I downloaded the latest > source and compiled. The trace is using that binary not the distro > supplied (Ver. 1.30). I should note that I already tried the fresh > compiled version before and got the same results as the distro version. > > > > On Mon, Aug 8, 2016 at 9:19 AM, Miroslav Lichvar > wrote: > >> On Mon, Aug 08, 2016 at 09:05:03AM -0400, Chris Greenman wrote: >> > I didn't think the -F option was correct but it didn't seem to work >> without >> > it either. I was just hunting and pecking. My gps does not (directly) >> > provide PPS. It's a ublox 6 so I could probably wire it in but to be >> > honest, I don't need that much precision. For my needs NTP is accurate >> > enough but it's not always available which is why I want time from GPS. >> >> Note that GPS without PPS is typically less stable than NTP over >> internet. Binary mode may work better than NMEA. >> >> > As >> > for the dependencies and starting order, that's easy to fix. Right now >> > gpsd is starting from init.d and chrony is starting from systemd. I can >> > just remove the rc#.d links and write a new .service file for gpsd with >> > "After = chrony.service" and "Wanted by = default.target". Then verify >> the >> > chrony service file jives with the one for gpsd. >> >> With SHM refclock that shouldn't be necessary. Only for SOCK chronyd >> needs to be started first. >> >> > The last gps strace I posted was with the -D 8 option specified. I did >> > not, however, specify -f to strace so it is not following after it >> forks. >> >> The -N option disables forking. Another useful option is -n, which >> tells gpsd to not wait for clients, so SHM is always updated. >> >> > As soon as I get some play time today I'll run some new traces. Is >> > attaching the best way to send the files or is there a bit bucket >> somewhere >> > I should use? >> >> I think it's ok to post here if it's not too large (e.g. > 100KB). Or >> you can compress it first. >> >> -- >> Miroslav Lichvar >> >> -- >> To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org >> with "unsubscribe" in the subject. >> For help email chrony-users-requ...@chrony.tuxfamily.org >> with "help" in the subject. >> Trouble? Email listmas...@chrony.tuxfamily.org. >> >> >
Re: [chrony-users] Not getting time from gpsd
Thanks. I already enabled my NTP sources and you're right, the gps is getting marked as bad. I'll play with that today. Chris On Aug 9, 2016 4:42 AM, "Miroslav Lichvar" wrote: > On Mon, Aug 08, 2016 at 01:21:56PM -0400, Chris Greenman wrote: > > 210 Number of sources = 1 > > MS Name/IP address Stratum Poll Reach LastRx Last sample > > > > > === > > #* GPS 0 4 37717 +296us[ +347us] +/- > > 200ms > > > > > > I am perfectly happy with 200ms error in time. That more than suits my > > needs. > > You might want to try this with some NTP sources and see how accurate > is the GPS time source. From that you would adjust the offset value on > the refclock SHM line so the the error is reduced and the GPS source > is not marked as a falseticker when there are other source. I'd also > suggest to add "minsamples 64" to the refclock directive, so chronyd > doesn't try to follow short-term variations in the measured offset > (the error in the message based GPS time tends to be non-random). > > -- > Miroslav Lichvar > > -- > To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org > with "unsubscribe" in the subject. > For help email chrony-users-requ...@chrony.tuxfamily.org > with "help" in the subject. > Trouble? Email listmas...@chrony.tuxfamily.org. > >
Re: [chrony-users] Not getting time from gpsd
Ok I took out the offset, precision, and delay. I let everything stabilize a bit and then took 3 samples. Here's what it came up with. $ date && chronyc sources Tue 9 Aug 08:54:52 EDT 2016 210 Number of sources = 5 MS Name/IP address Stratum Poll Reach LastRx Last sample === #* GPS 0 4 37715 +1479us[+1575us] +/- 522us ^? clockb.ntpjs.org 0 6 0 - +0ns[ +0ns] +/- 0ns ^- proxmox.undeadarmy.com2 6 7 8-63ms[ -63ms] +/- 87ms ^- host2.kingrst.com 2 6 7 9-72ms[ -72ms] +/- 91ms ^- clock.xmission.com1 6 7 8-65ms[ -65ms] +/- 41ms irishmistii@IrishMistII:~ $ date && chronyc sources Tue 9 Aug 08:55:00 EDT 2016 210 Number of sources = 5 MS Name/IP address Stratum Poll Reach LastRx Last sample === #* GPS 0 4 37712 -606us[-1568us] +/- 422us ^? clockb.ntpjs.org 0 6 0 - +0ns[ +0ns] +/- 0ns ^- proxmox.undeadarmy.com2 6 716-62ms[ -63ms] +/- 87ms ^- host2.kingrst.com 2 6 716-71ms[ -72ms] +/- 91ms ^- clock.xmission.com1 6 716-64ms[ -65ms] +/- 41ms irishmistii@IrishMistII:~ $ date && chronyc sources Tue 9 Aug 08:55:08 EDT 2016 210 Number of sources = 5 MS Name/IP address Stratum Poll Reach LastRx Last sample === #* GPS 0 4 37720 -606us[-1568us] +/- 422us ^? clockb.ntpjs.org 0 6 0 - +0ns[ +0ns] +/- 0ns ^- proxmox.undeadarmy.com2 6 724-62ms[ -63ms] +/- 87ms ^- host2.kingrst.com 2 6 725-71ms[ -72ms] +/- 91ms ^- clock.xmission.com1 6 724-64ms[ -65ms] +/- 41ms On Tue, Aug 9, 2016 at 8:10 AM, Chris Greenman wrote: > Thanks. I already enabled my NTP sources and you're right, the gps is > getting marked as bad. I'll play with that today. > > Chris > > On Aug 9, 2016 4:42 AM, "Miroslav Lichvar" wrote: > >> On Mon, Aug 08, 2016 at 01:21:56PM -0400, Chris Greenman wrote: >> > 210 Number of sources = 1 >> > MS Name/IP address Stratum Poll Reach LastRx Last sample >> > >> > >> === >> > #* GPS 0 4 37717 +296us[ +347us] +/- >> > 200ms >> > >> > >> > I am perfectly happy with 200ms error in time. That more than suits my >> > needs. >> >> You might want to try this with some NTP sources and see how accurate >> is the GPS time source. From that you would adjust the offset value on >> the refclock SHM line so the the error is reduced and the GPS source >> is not marked as a falseticker when there are other source. I'd also >> suggest to add "minsamples 64" to the refclock directive, so chronyd >> doesn't try to follow short-term variations in the measured offset >> (the error in the message based GPS time tends to be non-random). >> >> -- >> Miroslav Lichvar >> >> -- >> To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org >> with "unsubscribe" in the subject. >> For help email chrony-users-requ...@chrony.tuxfamily.org >> with "help" in the subject. >> Trouble? Email listmas...@chrony.tuxfamily.org. >> >>
Re: [chrony-users] Not getting time from gpsd
Ok I set it to 0.0065 offset. Here's my chrony.conf pool pool.ntp.org driftfile /var/lib/chrony/drift allow refclock SHM 0 refid GPS offset 0.065 #refclock SHM 0 refid GPS precision 1e-1 offset 0. delay 0.2 makestep 1 -1 and here is the chrony sources output: irishmistii@IrishMistII:~ $ chronyc sources 210 Number of sources = 5 MS Name/IP address Stratum Poll Reach LastRx Last sample === #* GPS 0 4 37712 +2112us[+2967us] +/- 325us ^- orchid.sidereal.ca2 61719+11ms[ +12ms] +/- 40ms ^- static-96-244-96-19.bltmm 2 61719+11ms[ +12ms] +/- 40ms ^- hydrogen.constant.com 2 61718+14ms[ +15ms] +/- 32ms ^- host2.kingrst.com 2 61519 +9078us[ +10ms] +/- 100ms irishmistii@IrishMistII:~ $ chronyc sources 210 Number of sources = 5 MS Name/IP address Stratum Poll Reach LastRx Last sample === #* GPS 0 4 377 9 +132us[ +236us] +/- 339us ^- orchid.sidereal.ca2 61750 +9849us[ +12ms] +/- 40ms ^- static-96-244-96-19.bltmm 2 61751 +9227us[ +12ms] +/- 40ms ^- hydrogen.constant.com 2 61750+13ms[ +15ms] +/- 32ms ^- host2.kingrst.com 2 61551 +7529us[ +10ms] +/- 100ms irishmistii@IrishMistII:~ $ chronyc sources 210 Number of sources = 5 MS Name/IP address Stratum Poll Reach LastRx Last sample === #* GPS 0 4 377 9 +2596us[+3043us] +/- 464us ^- orchid.sidereal.ca2 63713+14ms[ +14ms] +/- 39ms ^- static-96-244-96-19.bltmm 2 63713 +9722us[ +10ms] +/- 44ms ^- hydrogen.constant.com 2 63713+14ms[ +14ms] +/- 33ms ^- host2.kingrst.com 2 61578 +6938us[ +10ms] +/- 100ms On Tue, Aug 9, 2016 at 9:25 AM, Bill Unruh wrote: > So GPS is what the system is using to set the time. clockb.ntpis.org is > not > responding at all. The other three have responded three times, and have not > been queried again during the very brief time you have make these tests. > They claim that your system time is out by about 60-70ms so you might want > to use > that as an offset for the GPS clock. > > I have no idea why clockb is claiming to be stratum 0 except that that is > probably the default stratum if the remote clock is unreachable. I would > have > thought 15 was a more reasonable value for that, but > > > > On Tue, 9 Aug 2016, Chris Greenman wrote: > > Ok I took out the offset, precision, and delay. I let everything >> stabilize a bit and then took 3 samples. >> Here's what it came up with. >> $ date && chronyc sources >> Tue 9 Aug 08:54:52 EDT 2016 >> 210 Number of sources = 5 >> MS Name/IP address Stratum Poll Reach LastRx Last sample >> >> >> === >> #* GPS 0 4 37715 +1479us[+1575us] +/- >> 522us >> ^? clockb.ntpjs.org 0 6 0 - +0ns[ +0ns] +/- >>0ns >> ^- proxmox.undeadarmy.com2 6 7 8-63ms[ -63ms] +/- >> 87ms >> ^- host2.kingrst.com 2 6 7 9-72ms[ -72ms] +/- >> 91ms >> ^- clock.xmission.com1 6 7 8-65ms[ -65ms] +/- >> 41ms >> >> irishmistii@IrishMistII:~ $ date && chronyc sources >> Tue 9 Aug 08:55:00 EDT 2016 >> 210 Number of sources = 5 >> MS Name/IP address Stratum Poll Reach LastRx Last sample >> >> >> === >> #* GPS 0 4 37712 -606us[-1568us] +/- >> 422us >> ^? clockb.ntpjs.org 0 6 0 - +0ns[ +0ns] +/- >>0ns >> ^- proxmox.undeadarmy.com2 6 716-62ms[ -63ms] +/- >> 87ms >> ^- host2.kingrst.com 2 6 716-71ms[ -72ms] +/- >> 91ms >> ^- clock.xmission.com1 6 716-64ms[ -65ms] +/- >> 41ms >> >> irishmistii@IrishMistII:~ $ date && chronyc sources >> Tue 9 Aug 08:55:08 EDT 2016 >> 210 Number of sources = 5 >> MS Name/IP address Stratum Poll Reach LastRx Last sample >> >> >> === >> #* GPS 0 4
Re: [chrony-users] Not getting time from gpsd
Ok cool.I'll stick that refclock line in and call it good. Thanks a bunch for all the help and tuning advise. I might try and grab some statistics during my race this week since I'll be on a cell phone LTE hotspot which can get spotty in areas. On Mon, Aug 22, 2016 at 4:26 AM, Miroslav Lichvar wrote: > On Fri, Aug 19, 2016 at 06:26:14PM -0400, Chris Greenman wrote: > > Finally got a chance to grab more stats.my refclock line now looks > like > > this: > > > > refclock SHM 0 refid GPS offset 0.060 delay 0.22 minsamples 64 > > > > > > I'm attaching the latest stats. > > You might want to try something like this: > refclock SHM 0 refid GPS offset 0.080 delay 0.2 minsamples 64 > > That should move the offset closer to zero. It will be still moving > around 10-20 milliseconds, but if your requirement was to keep the > clock accurate to one second, I think it will be good enough. > > -- > Miroslav Lichvar > > -- > To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org > with "unsubscribe" in the subject. > For help email chrony-users-requ...@chrony.tuxfamily.org > with "help" in the subject. > Trouble? Email listmas...@chrony.tuxfamily.org. > >
Re: [chrony-users] chrony icon ?
I would kinda rank chrony along with other small utilities like cat, and sed which I've never seem icons for either. Chrony isn't really a graphical program so in my opinion or doesn't need one. Your not going to run it outside a terminal anyway. That's my 2 cents anyway. On Sep 2, 2016 1:59 AM, "Bryan Christianson" wrote: > I’m just wondering if anyone has made an icon for chrony. Lots of other > daemons/utilities have an associated whizzy little picture and it would be > kind of nice to have something for chrony(c|d) in the graphically oriented > OS environments - e.g. macOS obviously. > > Whatroute on macOS can display network activity associated with processes > and chronyd looks a little stark with just its name and no image. > > I have absolutely no talent in designing icons, hence the request. > > — > Bryan Christianson > br...@whatroute.net > > > > > -- > To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org > with "unsubscribe" in the subject. > For help email chrony-users-requ...@chrony.tuxfamily.org > with "help" in the subject. > Trouble? Email listmas...@chrony.tuxfamily.org. > >
Re: [chrony-users] Using symbolic network names in /etc/chrony.conf file?
When you specify a hostname, that's it. It's a 32bit address (ipv4 of course). Throwing a netmask on it does nothing except specify that your network segment has 64,510 usable addresses. Now if you edit /etc/networks and add mynet 10.10.0.0 then you can use the mynet/16 notation in your chrony.conf On Jul 25, 2017 10:19 AM, "Miroslav Lichvar" wrote: > On Tue, Jul 25, 2017 at 08:37:18AM +0200, Miroslav Lichvar wrote: > > On Mon, Jul 24, 2017 at 08:24:57PM +, Parker, Michael D. wrote: > > > The chrony allow directive allows the addition of a symbolic hostname > in its > > > specification. However, I took a leap in entering the following > directive: > > > > > > allow hostname/16 > > > > > > which failed to do what I expected but no configuration file error was > > > flagged. > > > > This is not supported. If allow/deny has a hostname, it always applies > > to all 32 (for IPv4) or 128 bits (for IPv6). > > At least for now, I'll fix the parser to not allow slashes after > hostnames in the allow/deny directives/commands. > > -- > Miroslav Lichvar > > -- > To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org > with "unsubscribe" in the subject. > For help email chrony-users-requ...@chrony.tuxfamily.org > with "help" in the subject. > Trouble? Email listmas...@chrony.tuxfamily.org. > >
Re: [chrony-users] gpsd:ERROR... Permission denied
Just curious. Are you using the chrony and gpsd from the Raspbian Jessie repositories? If so, do yourself a favor and get rid of them both, download the latest source for BOTH and compile them yourself. I beat my head against a wall trying to get the repo versions to work but they are horribly outdated. Also verify the permission on /dev/pps0 and make sure the user running gpsd has access to the device file. On Feb 6, 2018 2:03 PM, "Bill Unruh" wrote: > I do send it as plain text and it has the usual Unix CR-LF at the end of > every > line of 70 or so characters. > > > > William G. Unruh __| Canadian Institute for| Tel: +1(604)822-3273 > Physics&Astronomy _|___ Advanced Research _| Fax: +1(604)822-5324 > UBC, Vancouver,BC _|_ Program in Cosmology | un...@physics.ubc.ca > Canada V6T 1Z1 | and Gravity __|_ www.theory.physics.ubc.ca/ > > On Tue, 6 Feb 2018, Charles Muggen wrote: > > I'm sorry, but your reply messages are appearing as one continuous stream >> of words. >> My mail server must be stripping linefeeds in both directions. >> Do you think you could send as plain text? >> Thanks! >> >> >> Sent: Tuesday, February 06, 2018 at 12:13 PM >>> From: "Bill Unruh" >>> To: chrony-users@chrony.tuxfamily.org >>> Subject: Re: [chrony-users] gpsd:ERROR... Permission denied >>> >>> William G. Unruh __| Canadian Institute for| Tel: +1(604)822-3273 >>> Physics&Astronomy _|___ Advanced Research _| Fax: +1(604)822-5324 >>> UBC, Vancouver,BC _|_ Program in Cosmology | un...@physics.ubc.ca >>> Canada V6T 1Z1 | and Gravity __|_ www.theory.physics.ubc.ca/ >>> On Tue, 6 Feb 2018, Charles Muggen wrote: > here are the results for >>> systemctl status chrony > > ● chrony.service - LSB: Controls chronyd NTP >>> time daemon > Loaded: loaded (/etc/init.d/chrony) > Active: active (exited) >>> since Tue 2018-02-06 16:56:53 UTC; 4min 28s ago > Process: 483 >>> ExecStart=/etc/init.d/chrony start (code=exited, status=0/SUCCESS) > > > by >>> the way, what is a recommended way to remove NTPd? > are there any >>> dependencies on NTP libs from chronyd? The easiest is jut to not install >>> ntpd.. The next is to make sure that neither in /etc/rc?.d or in >>> /lib/systemd there is nothing that calls ntpd. ntp is the protocol, and >>> chrony uses that protocol. ntpd is the reference implimentation of that >>> protocol to discipline the local clock, which would be in conflict with >>> chrony. > > > >> Sent: Monday, February 05, 2018 at 4:15 PM >> From: "Ariel >>> Garcia" >> To: chrony-users@chrony.tuxfamily.org >> Subject: Re: >>> [chrony-users] gpsd:ERROR... Permission denied >> >>> During reboot, I see >>> [OK] Started NTP client/server. >>> Is it okay for the NTP client/server to >>> be running next to chronyd? >> >> I guess that is the message printed when >>> starting chrony. >> Are you using systemd? >> >> Check chrony's systemd >>> status with >> # systemctl status chrony >> mine shows: >> chrony.service - >>> NTP client/server >> >> or just check the [Unit] Description field in >> >>> /lib/systemd/system/chrony.service >> or >> >>> /etc/systemd/system/chrony.service >> >> >> If you really have NTPd >>> running besides chrony, then you have two programs >> trying to "correct" >>> the same clock... which will make both misunderstand the >> clock drift. In >>> that case you must definitely chose one and turn off the other. >> Since >>> you are in the chrony mailing list, you must of course turn off NTPd >> off >>> ;-) >> >> -- >> Dr. Ariel García >> Gemfony scientific UG >>> (haftungsbeschränkt) >> Hauptstraße 2 >> D-76344 Eggenstein-Leopoldshafen >>> >> GERMANY >> >> Phone: +49 7247 934 2783 >> Fax: +49 7247 934 2781 >> >>> E-Mail: a.gar...@gemfony.eu >> Web: http://www.gemfony.eu >> >> >>> Geschäftsführer: Dr. Rüdiger Berlich >> HandelsregisterNr: HRB 710566, >>> Amtsgericht Mannheim, Ust-IdNr: DE274421406 >> >> >> -- >> To unsubscribe >>> email chrony-users-requ...@chrony.tuxfamily.org >> with "unsubscribe" >>> in the subject. >> For help email chrony-users-requ...@chrony.tu >>> xfamily.org >> with "help" in the subject. >> Trouble? Email >>> listmas...@chrony.tuxfamily.org. >> >> > > -- > To unsubscribe email >>> chrony-users-requ...@chrony.tuxfamily.org > with "unsubscribe" in the >>> subject. > For help email chrony-users-requ...@chrony.tuxfamily.org > >>> with "help" in the subject. > Trouble? Email >>> listmas...@chrony.tuxfamily.org. > >>> >> >> -- >> To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org >> with "unsubscribe" in the subject. >> For help email chrony-users-requ...@chrony.tuxfamily.org >> with "help" in the subject. >> Trouble? Email listmas...@chrony.tuxfamily.org. >> >
Re: [chrony-users] Time synchronisation over a high-latency packet radio network
Is there any possibility of using GPS for time? I had a similar dilemma on my raspberry pi based boat computer. I didn't want to rely on internet provided time since it might not be available if away from the slip. On Tue, May 7, 2019, 11:30 AM Lonnie Abelbeck wrote: > > > > On May 6, 2019, at 10:53 PM, Stuart Longland > wrote: > > > > Hi all, > > > > I've got a problem where I need to provide a time synchronisation > > service for small embedded computers whose only link to the outside > > world is a slow and high-latency packet radio network. > > Stuart, Indeed very interesting... > > > Below is my chronyd.conf: > > - BEGIN chronyd.conf - > > # Welcome to the chrony configuration file. See chrony.conf(5) for more > > # information about usuable directives. > > pool 2.debian.pool.ntp.org iburst > > > > # NTP proxy over APRS > > server 127.0.0.1 port 3123 trust maxdelay 10 minpoll 3 > > Just curious, it appears you have native DNS, why do you need to proxy NTP > over APRS (unless you use a similar technique for DNS). > > BTW, at startup our project always steps the time using (8 second timeout > would be too low for you): > -- > chronyd -q -t 8 "server time.example.tld iburst" > -- > before starting "chronyd" in the background. (no systemd). > > Lonnie > > > -- > To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org > with "unsubscribe" in the subject. > For help email chrony-users-requ...@chrony.tuxfamily.org > with "help" in the subject. > Trouble? Email listmas...@chrony.tuxfamily.org. > >
