subject:"\[chrony\-users\] Not getting time from gpsd"

Re: [chrony-users] Not getting time from gpsd

2016-08-22 Thread Chris Greenman

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] Not getting time from gpsd

2016-08-14 Thread Bill Unruh


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 _|___ 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 _|___ 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

2016-08-14 Thread Chris Greenman

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 _|___ 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

2016-08-14 Thread Chris Greenman

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 _|___ 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

2016-08-10 Thread Miroslav Lichvar

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

2016-08-09 Thread Chris Greenman

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

Re: [chrony-users] Not getting time from gpsd

2016-08-09 Thread Miroslav Lichvar

On Tue, Aug 09, 2016 at 09:08:33AM -0400, 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.

Ok, this shows that the offset between uncorrected GPS and NTP sources
is around 65 milliseconds, so the refclock line should have something
like "offset 0.065".
> 
> $ 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

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

2016-08-09 Thread Chris Greenman

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

2016-08-09 Thread Bill Unruh

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   377    15  +1479us[+1575us] +/-  522us
^? clockb.ntpjs.org              0   6     0     -     +0ns[   +0ns] +/-    0ns
^- proxmox.undeadarmy.com        2   6     7     8    -63ms[  -63ms] +/-   87ms
^- host2.kingrst.com             2   6     7     9    -72ms[  -72ms] +/-   91ms
^- clock.xmission.com            1   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   377    12   -606us[-1568us] +/-  422us
^? clockb.ntpjs.org              0   6     0     -     +0ns[   +0ns] +/-    0ns
^- proxmox.undeadarmy.com        2   6     7    16    -62ms[  -63ms] +/-   87ms
^- host2.kingrst.com             2   6     7    16    -71ms[  -72ms] +/-   91ms
^- clock.xmission.com            1   6     7    16    -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   377    20   -606us[-1568us] +/-  422us
^? clockb.ntpjs.org              0   6     0     -     +0ns[   +0ns] +/-    0ns
^- proxmox.undeadarmy.com        2   6     7    24    -62ms[  -63ms] +/-   87ms
^- host2.kingrst.com             2   6     7    25    -71ms[  -72ms] +/-   91ms
^- clock.xmission.com            1   6     7    24    -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   377    17   +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

2016-08-08 Thread Bryan Christianson

Debian jessie gets the start dependencies wrong and starts gpsd before starting 
chronyd.

The simple fix is to stop gpsd, wait a few seconds and then restart it. It 
should then attach to the chrony listening socket.

A long term fix is to sort out the dependencies. There was a lot of discussion 
of this on the gpsd mail list a few months back. A search of the their archives 
may be helpful.


> On 8/08/2016, at 4:21 PM, Steve Horton  wrote:
> 
> I see gpsd using the socket but I don't see chrony accessing it at all. Can 
> you comment out the shm line and strace chrony again? I think that's where 
> the issue is.
> 
> 
> On Aug 7, 2016 10:27 PM, "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
> 
> 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.



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] Not getting time from gpsd

2016-08-08 Thread Miroslav Lichvar

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

2016-08-08 Thread Chris Greenman

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

2016-08-08 Thread Chris Greenman

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

2016-08-08 Thread Miroslav Lichvar

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

2016-08-08 Thread Steve Horton

I see gpsd using the socket but I don't see chrony accessing it at all. Can
you comment out the shm line and strace chrony again? I think that's where
the issue is.

On Aug 7, 2016 10:27 PM, "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
>
> 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) [ "$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 $?
>>>;;
>>>

Re: [chrony-users] Not getting time from gpsd

2016-08-07 Thread Chris Greenman

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) [ "$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

Re: [chrony-users] Not getting time from gpsd

2016-08-07 Thread Steve Horton

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) [ "$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

Re: [chrony-users] Not getting time from gpsd

2016-08-07 Thread Chris Greenman

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

Re: [chrony-users] Not getting time from gpsd

2016-08-07 Thread Steve Horton

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

2016-08-06 Thread Chris Greenman

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

2016-08-06 Thread Steve Horton

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

2016-08-06 Thread Chris Greenman

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 _|___ 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
>>> >> ^* 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

Re: [chrony-users] Not getting time from gpsd

2016-08-06 Thread Chris Greenman

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

2016-08-06 Thread Steve Horton

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 _|___ 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
>> >> ^* 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

2016-08-06 Thread Chris Greenman

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

2016-08-06 Thread Bill Unruh


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 _|___ 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" 
 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   377    56  +9749us[  
+11ms] +/-   18ms
>> ^- 104.156.99.226                2   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 
>> key        shmid      owner      perms      bytes      nattch    
 status      
>> 0x4e545030 0          root       600        80         2         
              
>> 0x4e545031 32769      root       600        80         1
>>
> Any idea why chrony isn't getting time from the GPS?
>
> Thanks

Re: [chrony-users] Not getting time from gpsd

2016-08-06 Thread Bill Unruh

OOps, that is 
log refclocks ...

and look in /var/log/chrony/refclocks.log
Sorry.


William G. Unruh __| Canadian Institute for| Tel: +1(604)822-3273
Physics _|___ 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, 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   377    56  +9749us[  +11ms] 
+/-   18ms
  >> ^- 104.156.99.226                2   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 
  >> key        shmid      owner      perms      bytes      nattch     
status      
  >> 0x4e545030 0          root       600        80         2               
        
  >> 0x4e545031 32769      root       600        80         1
  >>
  > Any idea why chrony isn't getting time from the GPS?
  >
  > Thanks

Re: [chrony-users] Not getting time from gpsd

2016-08-06 Thread Bill Unruh


Is there anything in /var/log/chrony/refclock.

Make sure that you have
logdir /var/log/chrony
log refclock 
(the dots are for other things you might want to log. Measurements would be
the next one I would choose.)

restart chrony and then look in /var/log/chrony/refclock to see what, if
anything, is there.


William G. Unruh __| Canadian Institute for| Tel: +1(604)822-3273
Physics _|___ 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, 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   377    56  +9749us[  +11ms] 
+/-   18ms
  >> ^- 104.156.99.226                2   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 
  >> key        shmid      owner      perms      bytes      nattch     
status      
  >> 0x4e545030 0          root       600        80         2               
        
  >> 0x4e545031 32769      root       600        80         1
  >>
  > Any idea why chrony isn't getting time from the GPS?
  >
  > Thanks

Re: [chrony-users] Not getting time from gpsd

2016-08-06 Thread Steve Horton

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

[chrony-users] Not getting time from gpsd

2016-08-06 Thread Chris Greenman

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

Re: [chrony-users] Not getting time from gpsd

Re: [chrony-users] Not getting time from gpsd

Re: [chrony-users] Not getting time from gpsd

Re: [chrony-users] Not getting time from gpsd

Re: [chrony-users] Not getting time from gpsd

Re: [chrony-users] Not getting time from gpsd

Re: [chrony-users] Not getting time from gpsd

Re: [chrony-users] Not getting time from gpsd

Re: [chrony-users] Not getting time from gpsd

Re: [chrony-users] Not getting time from gpsd

Re: [chrony-users] Not getting time from gpsd

Re: [chrony-users] Not getting time from gpsd

Re: [chrony-users] Not getting time from gpsd

Re: [chrony-users] Not getting time from gpsd

Re: [chrony-users] Not getting time from gpsd

Re: [chrony-users] Not getting time from gpsd

Re: [chrony-users] Not getting time from gpsd

Re: [chrony-users] Not getting time from gpsd

Re: [chrony-users] Not getting time from gpsd

Re: [chrony-users] Not getting time from gpsd

Re: [chrony-users] Not getting time from gpsd

Re: [chrony-users] Not getting time from gpsd

Re: [chrony-users] Not getting time from gpsd

Re: [chrony-users] Not getting time from gpsd

Re: [chrony-users] Not getting time from gpsd

Re: [chrony-users] Not getting time from gpsd

Re: [chrony-users] Not getting time from gpsd

Re: [chrony-users] Not getting time from gpsd

[chrony-users] Not getting time from gpsd

30 matches

Site Navigation

Mail list logo

Footer information