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

[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

[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] Getting chrony status

[Miroslav Lichvar]

On Tue, Aug 09, 2016 at 09:47:28AM +0200, Mauro Condarelli wrote:
> Il 08/08/2016 10:34, Miroslav Lichvar ha scritto:
> > "time has settled down", you might need to check also the "System
> Problem is on target I have unreliable Internet connection.
> This means i might not have connection at all at boot-time.
> In this condition it's ok to rely on RTC alone.
> What I need is to be sure chronyc did require initializations (e.g.: it did 
> set system clock from RTC) even if not fully synchronized.

If you need to wait for "chronyd -s" to set the system clock from the
RTC, just wait until the foreground chronyd process exits. If it's
started from an init script (or systemd service with Type=Forking),
the clock will be already set when the service is ready. It takes
couple seconds.

> > http://chrony.tuxfamily.org/doc/2.4/chronyc.html#waitsync
> How does that behave in case of disconnected target?

The leap status, which waitsync checks, is set only when synchronized
to a real time source (NTP or refclock), so it will wait forever or
timeout if the maximum number of tries is set.

> I also have a very strange and annoying behavior I need to debug, somehow:
> It happens (rarely, about once in a few days) system time, as seen using 
> either "date" or "time(null)", "jumps around" for a short while and then 
> resets to normal.
> I mean I have record of time going in the past (two days), then in the future 
>  (> one month) then in the past again (>one week) and finally going back to 
> "right" time.
> I spotted this because my target (embedded ARM) has a display that, when 
> idle, just displays system time (fetched using "time(null)"), I casually 
> spotted the bogus time and confirmed this was not a problem with my 
> application by connecting to console and issuing several "date" commands.
> 
> Real question is:
> How do I debug such situation?
> Should I see something on log? (I didn't spot anything suspicious)
> How can I tell chrony to log any correction done to sysclock?

If you enable the "tracking" log, it will contain all corrections from
NTP sources and reference clocks. The initial correction from the RTC
with the -s option is only logged to the system log and there should
be at most one step and one slew per start. If you see more steps when
no NTP sources are available, it's probably something else messing
with the clock.

-- 
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] Getting chrony status

[Mauro Condarelli]

Thanks Miroslav.
Comments below.

Il 08/08/2016 10:34, Miroslav Lichvar ha scritto:

On Sun, Aug 07, 2016 at 05:06:46AM +0200, Mauro Condarelli wrote:

Thanks Steve.
I know about "chronyc tracking", but that is human-readable info.
I need to parse it (in a shell script) to delay starting of my app until time 
has settled down.
Is it enough to wait for "Leap status" to go to "Normal"?
... or should I take into consideration other values?.

Depending on how chronyd is configured and what exactly you mean by

My current /etc/chrony .conf is:
-
server 0.it.pool.ntp.org
server 1.it.pool.ntp.org
server 2.pool.ntp.org
server 3.pool.ntp.org

logdir /var/log/chrony
log rtc statistics measurements tracking
logchange 1
driftfile /var/lib/chrony/drift
keyfile /etc/chrony.keys
generatecommandkey
makestep 1.0 3
maxupdateskew 100.0
dumponexit
dumpdir /var/lib/chrony
rtconutc
rtcfile /var/lib/chrony/rtc
bindcmdaddress /var/run/chrony/chronyd.sock

rtcdevice /dev/rtc0
-

"time has settled down", you might need to check also the "System

Problem is on target I have unreliable Internet connection.
This means i might not have connection at all at boot-time.
In this condition it's ok to rely on RTC alone.
What I need is to be sure chronyc did require initializations (e.g.: it did set 
system clock from RTC) even if not fully synchronized.

time" and "Skew" values.

The chronyc waitsync command can do all this for you.

http://chrony.tuxfamily.org/doc/2.4/chronyc.html#waitsync

How does that behave in case of disconnected target?



I also have a very strange and annoying behavior I need to debug, somehow:
It happens (rarely, about once in a few days) system time, as seen using either "date" or 
"time(null)", "jumps around" for a short while and then resets to normal.
I mean I have record of time going in the past (two days), then in the future  (> one month) 
then in the past again (>one week) and finally going back to "right" time.
I spotted this because my target (embedded ARM) has a display that, when idle, just displays system 
time (fetched using "time(null)"), I casually spotted the bogus time and confirmed 
this was not a problem with my application by connecting to console and issuing several 
"date" commands.

Real question is:
How do I debug such situation?
Should I see something on log? (I didn't spot anything suspicious)
How can I tell chrony to log any correction done to sysclock?

TiA

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

[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

[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] Getting chrony status

[Bill Unruh]

I also have a very strange and annoying behavior I need to debug, somehow:
It happens (rarely, about once in a few days) system time, as seen using 
either "date" or "time(null)", "jumps around" for a short while and then 
resets to normal.
I mean I have record of time going in the past (two days), then in the future 
(> one month) then in the past again (>one week) and finally going back to 
"right" time.


Uh, that certainly should not happen, and that should be reflected in all the
log files. Have you looked at the "measurements" log and seen the time
jumping? Is it one of the pool servers or a few or all of them? (the latter
might suggest that there is some program resetting the time for you that you
are running.)

I spotted this because my target (embedded ARM) has a display that, when 
idle, just displays system time (fetched using "time(null)"), I casually


What is "time(null)"? Are you sure that your program for displaying the time
is not screwed up?

spotted the bogus time and confirmed this was not a problem with my 
application by connecting to console and issuing several "date" commands.


Real question is:
How do I debug such situation?


You start with the logs. What is the behaviour of "measurements" around that
time. What is the behaviour of the other logs around that time.


Should I see something on log? (I didn't spot anything suspicious)
How can I tell chrony to log any correction done to sysclock?


What does that mean? It does log steps, which is what this sounds like.



TiA

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