Re: [chrony-users] Understand why system clock is bad even though chrony offsets look fine

[Bill Unruh]

On Mon, 20 May 2024, Miroslav Lichvar wrote:


[CAUTION: Non-UBC Email]

On Thu, May 16, 2024 at 06:01:10PM +0530, Abhijith Sethuraj wrote:

> Is this server synchronized to the same NTP server as the computer

running the client application? What root distance does it report?
The server is synchronized to another NTP server that we don't have 
control
over. So, I don't think it's possible for me to give you the root 
distance.

It's safe to assume that the server's time is good, as they have a lot of
other clients apart from us and no one else reported any issues.


Actually that is usually a lie. It is used by companies to get rid of
complaints without doing anything. "No one else complains". It is also true
that if someone does complain it usually represents a huge number of others
who have problems and who do not complain, either because they do not notice
the problems, or do not complain because it is too much trouble.


--
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] Understand why system clock is bad even though chrony offsets look fine

[Bill Unruh]

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 __|_theory.physics.ubc.ca/

On Mon, 20 May 2024, Miroslav Lichvar wrote:


[CAUTION: Non-UBC Email]

On Thu, May 16, 2024 at 06:01:10PM +0530, Abhijith Sethuraj wrote:

> Is this server synchronized to the same NTP server as the computer

running the client application? What root distance does it report?

The server is synchronized to another NTP server that we don't have control
over. So, I don't think it's possible for me to give you the root distance.
It's safe to assume that the server's time is good, as they have a lot of
other clients apart from us and no one else reported any issues.


This sounds like a stock exchange.

Can you make a graph of the difference between the server and client
timestamps you see in your application? You could specify a small
offset correction in your chrony.conf to minimize the chance it will
fall outside of the allowed range.


Sorry, I have one more question here. So, I have three sources here and one
among those is preferred (this server is in the same site as my client, the
other two are elsewhere). Looking through my measurements log, I see that
we're seeing a lot of testC failures for the duration of the issue. We're
polling the local server rapidly (minpoll, maxpoll of -4 and filter 5). Is


Why? That is terrible for determining the rate offset of the clock. It means
that whenever there is trouble determining the time, your clock will drift
terribly. And the source clock also experiences time offset errors, and this
means that your clock will experience both the remote clocks errors and its
own and the transmission time errors as well. For any pairs of clocks there is
an "optimum" poll rate to get the best time, and it almost certainly is not
poll -4.



it possible that since there are a lot of testC failures (almost 16
failures within a second, when the polling frequency should also be ~16
times) and since the other two sources are not preferred (also their
offsets would be bad compared to the local one), we try to use the freq


So you are trying to do chrony's job for it? Badly?


adjustment in driftfile till we get good packets from the preferred source
or till we choose one of the non-preferred sources as the best source?


If NTP measurements of the selected source are failing some of the
tests, the clock will not be updated (unless the fallbackdrift option
is enabled) and it will drift on its own, mostly due to temperature
changes.

With such high polling rates you should consider enabling the
maxdelayquant option. That should limit the length of the runs with
failed test C.

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




--
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] Understand why system clock is bad even though chrony offsets look fine

[Bill Unruh]

The only way you can find the time error of a computer is to have a more
accurate time available. Using network clocks to determine the error is
subject to huge uncertainties. Get a cheap gps timeing receiver ( they are
about $50), and compare your system time against that.

The root distance is the maimum that yur clock could deviate from that source.
it is NOT a good measure of the error of your system closk. It assumes tht the
transmission from your system to the root source is instantaneous and return
is the whole or the root distance (or vice versa) Clearly a very bed set of
assumptions, But its purpose is NOT to estimate the error of your system, but
the worst case scenarion. If you want beter, get a better root source ( as I
said gps receivers are almost a dime a dozen, but if your system is at the
bottom  of a gold mine shaft, then the gps route is not the wat to go.

I have no idea why your system would crash. Sounds to me like really
incompentnt programming.

Note that using that timestamp inside a packet is probably one of the bad ways
of determining the time. That was why Mills developed ntp protocol.




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 __|_theory.physics.ubc.ca/

On Tue, 14 May 2024, Abhijith Sethuraj wrote:


[CAUTION: Non-UBC Email]> How did you measure that 50us error? Can you use that 
source of time
> for synchronization?
Unfortunately, we can't use that as a source. This difference is what an 
application noticed when it was looking at a
timestamp that's there inside a data packet (think of it as tx timestamp from a 
server that we don't have control over)
and what's obtained from system clock via gettimeofday() right when it received 
the data packet. The reason why we
noticed this was because the timestamp from system clock turned out to be 
lesser than the tx timestamp, which makes the
app crash. The network delays through switches and servers likely come to 
around 50us, which is how we measured it. What


ntp is precisely designed to lessen that tranport error, often by factors of
10 or more. The tranport delay is usually approxomate;y symmetric. And tat is
used\to correct the transport delays. Why are you trying to second guess
chrony (or ntp)?


do you think is a good indication to catch these issues? Should we look at 
frequency/freq adjustment of system clock? So


Unfortunately in ignorance you are assuming you know better than Mills,
Curnoe, Lichvar,... THey have spent huge amounts of time trying to figure out
how best to set the system clock to a remote accurate time source.



far we were only relying on offsets from ref clock, but this issue made us 
think of time error (root distance) as well.
Is there anything else that you would recommend we monitor on our end to catch 
these issues? Also, if root distance is


As I said, get a better local time source(eg gps) is the way. Or get an oven
controlled high accuracy crystal time source which you can connect to gps.


~1ms, does that imply that the value of current time that I get from 
gettimeofday() essentially has an error of ~1ms or
is this just inferring to the error in measurements from source (and that the 
user-space app need not consider this)?


Thanks,
Abhijith



On Mon, Apr 22, 2024 at 12:05 PM Miroslav Lichvar  wrote:
  On Fri, Apr 19, 2024 at 02:44:21AM +0530, Abhijith Sethuraj wrote:
  > Hello,
  >
  > I'm noticing issues with my system clock being inaccurate by almost 
50us,
  > even though "System time" in `chronyc tracking` shows offsets in the 
order
  > of ns. This was noticed by an application that tried to get current 
time by
  > calling `gettimeofday()`.

  How did you measure that 50us error? Can you use that source of time
  for synchronization?

  > Root delay      : 0.73557 seconds
  >
  > Root dispersion : 0.000997235 seconds

  Root distance (half of root delay + root dispersion) is over 1
  millisecond here. That's an estimate of maximum clock error due to
  asymmetries and clock instability.

  > almost similar to "root dispersion"? Also, what recommendations do you 
have
  > for monitoring chrony, so that I can catch this before it affects my 
app?
  > Also, are there any config tweaks that I can try out here to help me?

  You need a better server, one that has a smaller root dispersion and
  hardware timestamping on both the server and client to get the maximum
  error below 50 microseconds.

  --
  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] Re: Linux time goes wrong after changing the time with 'date' cmd

[Bill Unruh]

On Mon, 13 May 2024, Feng Tang wrote:


[CAUTION: Non-UBC Email]

Hi Miroslav Lichvar,

On Mon, May 13, 2024 at 08:19:07AM +0200, Miroslav Lichvar wrote:

On Mon, May 13, 2024 at 09:02:31AM +0800, Feng Tang wrote:

So my thought is, since user already chose to trust 'chrony', and
when chrony has more realiable NTP time source, 'chrony' can help to
correct the 'wrong date' set by user with the right time, practically
'rejecting' the huge time jump set by users.


chronyd is trying to correct the clock, but a typical default
configuration provided with distro packages allows steps only on
start, so the ~10% slew can take very long time.


Yes, exactly. In the above case, we saw the system time was compensated
very slowly.


It slews at 1 sec per 10 sec. if the clock is way out.





The user would need to allow steps at any time. See this answer in
the FAQ:
https://chrony-project.org/faq.html#_is_chronyd_allowed_to_step_the_system_clock


This works great in my test and the issue can't be reproduced. Many
thanks for the hint!


BUT you have to tell you users NOT to change the clock on their own. DO NOT
USE date to change the clock. If your users are going to do idiotic things
there is nothing you can do to correct all of their idiocies. Do not do it "as
a test" It is not a test. Nothing will ever make the clock suddeny jump time. 
NOt allowing your clocks to jump may well produce worse things that you are

complaining of now.


- Feng



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




--
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] Silent Failure -- Enhancement Request

[Bill Unruh]

It wounds like you are saying that there is only one source. That is very bead
practice, as the chrony and ntp notes state. You should have at least three
sources, precisely for the cases like yours. If one source dies you have
backups. 
So the default configuration on your end should be 3-5 sources. It probably

does not matter if the other sources are of lower quality than the one. They
are a backup.


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 __|_theory.physics.ubc.ca/

On Fri, 19 Apr 2024, Chris Knox wrote:


[CAUTION: Non-UBC Email]

Bryah, thanks for the answer.  Yes, now that we have the scars, we're 
monitoring chronyd's health carefully.  But my question goes a bit beyond that. 
 If chronyd is configured and running, that implies that the owner of the 
system wants the time to be correct. If the configured time source is not 
reachable, it seems at least as important as chronyd being out by a half-second 
and worth logging to syslog where someone who is not a time synchronization 
expert will notice something being amiss.  In effect, chronyd will tell me if 
it has a figurative hangnail, but will suffer in silence if it is starving.

I would suggest the Chrony authors add a default configuration to call for help 
if the time source is unreachable.  Is this an appropriate venue to ask for 
that enhancement?


--
Chris Knox
IT Infrastructure Engineer
tel 1.602.308.5438
18615 N. Claret Dr., Scottsdale, AZ  85255
christopher.k...@choicehotels.com

-Original Message-
From: Bryan Christianson 
Sent: Thursday, April 18, 2024 4:28 PM
To: chrony-users@chrony.tuxfamily.org
Subject: Re: [chrony-users] Silent Failure -- Enhancement Request

You could monitor the Reach field of chronyc and check that it has a value of 
377, raising an appropriate alarm for your system on failure.


On 19 Apr 2024, at 10:45, Chris Knox  wrote:

We recently moved a bunch of systems out of a data center and shut it down.  
Time sync was an overlooked item in the move.  As a result, the time server was 
not reachable, but it did not become apparent until servers started drifting 
enough to create issues.  Looking in the syslog of the various systems, the 
only entries I see are when chronyd could again hit the time server.  Over the 
previous weeks, chronyd suffered in silence until we were able to establish a 
valid time server, at which point log entries came fast and furious because the 
time was more than .5 seconds out.  Yet there was no message for all that time 
(several months) during which one server drifted out synch by more than 30 
seconds.  Is there a configuration in chrony.conf to complain when the time 
server is not reachable?  If there is, why isn’t that the default behavior?
 --
Chris



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] Re: Using gpsd

[Bill Unruh]

There are three problems with NMEA for timing. One is the length of time that an
NMEA phrase takes to communicate. (hundres of milliseconds). Second is that the
length of the NMEA sentence varies, and thus that time is not constant and
will fluctuate by many milliseconds. Third, the gps module places a low
priority on the NMEA sentences and sends them only when all other calculations
it does on the signals have finished, as I understand it. Again, many 
milliseconds, esp if you are
tracking a variable number of sattelites. IF you want accurate timing(sub
millisecond), use
PPS (good to microseconds or hundred nanoseconds with a bit of work).
If say a tenth of a second  accuracy is fine, then use NMEA.





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 __|_theory.physics.ubc.ca/

On Wed, 20 Mar 2024, infection.many...@aceecat.org wrote:


[CAUTION: Non-UBC Email]

On Tue, Mar 19, 2024 at 11:48:24PM -0700, Bill Unruh wrote:


FWIW, I'm testing a daemon that reads an *i2c* gps device and
feeds to chrony, and I need to bias it by about 0.250s -- I think
it is just that slow to read the bytes from i2c. But I'm still
looking for a foolish logic error like you suggest.



That would surprize me very much, unless you are doing a very slow
polling of the gps pps. .125 sec sound like the original IBMPC I
bought in 1980.  Maybe if you told us the hardware you are using and
the OS you are using someone could help more. Now if it is not PPS
but is rather reading the NMEA, then a slow baud rate could give you
that, since the sentences can be about that long at 600Bd. Also, you
really only need the NMEA for the first few seconds until the system
knows the seconds.


I can't (easily) use the PPS line because it's a separate pin, not
available over i2c. So yes, collecting NMEA lines.

Hardware: Raspberry Pi 3B+ with this gadget:

https://learn.adafruit.com/adafruit-mini-gps-pa1010d-module

running legacy (32 bit) raspbian, and my hack here:

https://gist.github.com/nobrowser/285d63410b9c2aec77a53587020cf2b6

I still want to try reading i2c with a super-slim C program instead,
but I'm not too optimistic about it.

--
Ian

--
To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org
with "unsubscribe" in the subject.
For help email chrony-users-requ...@chrony.tuxfamily.org
with "help" in the subject.
Trouble?  Email listmas...@chrony.tuxfamily.org.




--
To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org 
with "unsubscribe" in the subject.
For help email chrony-users-requ...@chrony.tuxfamily.org 
with "help" in the subject.

Trouble?  Email listmas...@chrony.tuxfamily.org.

Re: [chrony-users] Re: Using gpsd

[Bill Unruh]

That would surprize me very much, unless you are doing a very slow polling of
the gps pps. .125 sec sound like the original IBMPC I bought in 1980.
Maybe if you told us the hardware you are using and the OS you are using
someone could help more. Now if it is not PPS but is rather reading the NMEA,
then a slow baud rate could give you that, since the sentences can be about
that long at 600Bd. Also, you really only need the NMEA for the first few
seconds until the system knows the seconds.


On Tue, 19 Mar 2024, infection.many...@aceecat.org wrote:


[CAUTION: Non-UBC Email]

On Tue, Mar 19, 2024 at 05:29:40PM -0700, Bill Unruh wrote:


refclock PPS /dev/pps0 lock NMEA refid GPS
refclock SOCK /var/run/chrony.clk.ttyS0.sock offset 0.5 delay 0.1 refid NMEA 
noselect



That says that the system is .5 sec out? Hard to believe. Maybe you
are using the wrong part of the pulse (clear rather than assert?)


FWIW, I'm testing a daemon that reads an *i2c* gps device and feeds to
chrony, and I need to bias it by about 0.250s -- I think it is just
that slow to read the bytes from i2c. But I'm still looking for a
foolish logic error like you suggest.

--
Ian

--
To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org
with "unsubscribe" in the subject.
For help email chrony-users-requ...@chrony.tuxfamily.org
with "help" in the subject.
Trouble?  Email listmas...@chrony.tuxfamily.org.




--
To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org 
with "unsubscribe" in the subject.
For help email chrony-users-requ...@chrony.tuxfamily.org 
with "help" in the subject.

Trouble?  Email listmas...@chrony.tuxfamily.org.

Re: [chrony-users] minstratum directive option

[Bill Unruh]

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 __|_theory.physics.ubc.ca/

On Wed, 20 Mar 2024, Sviatoslav Feshchenko wrote:


[CAUTION: Non-UBC Email]Hello,
The server directive has an option "minstratum" which increases the stratum of 
the
source to affect its preference. In opinion, there should also be an opposite


The stratum is a measure of how far away from the original source of the time
the server is. It is also a way of preventing loops. To arbitrarly decrease
the strantum makes is completely useless and can fool clients of that server
into thinking your system is better than it is. Bad idea
It is not set the preference. It is give some indication as to how good the
server's time is.


directive perhaps called "maxstratum" that will do the opposite. It will lower 
the
stratum of the source to affect its preference. Consider the official time of
Canada provided by the National Research Council of Canada (NRC). According to
their website (link below) they operate stratum 1 servers internally, and they 
also
operate stratum 2 server which get their time from the stratum 1 internal 
servers.
Public dissemination of NTP time is only available via their stratum 2 servers, 
but
not stratum 1 servers. Although I don't know their exact synchronisation 
mechanism
between their stratum 1 and stratum 2 server, considering that this is a 
government
organization providing the official time of Canada, it is likely that they use
highly accurate synchronisation methods. Their website states "For all practical
purposes, the average time disseminated by the stratum-2 server is the same as 
the
stratum-1 servers." It would therefore be reasonable in my opinion to be able to
adjust their NTP source from stratum 2 to stratum 1 in Chrony, and currently, 
there
is no such possibility.


Nor should there be any such possibility.



What are your thoughts on adding maxstratum option to the server directive that
decreases the stratum of a source for preference purposes? I think it makes 
sense
to have this option, and this option would only affect the preference of the
source. It would not affect the advertised stratum level of the chrony server to
its clients.


There are other ways of telling you system to use a specific server if that is
what you want.


NRC website 
link:https://nrc.canada.ca/en/certifications-evaluations-standards/canadas-official-tim
e/network-time-protocol-ntp

Many thanks to everyone, and Miroslav in particular.




--
To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org 
with "unsubscribe" in the subject.
For help email chrony-users-requ...@chrony.tuxfamily.org 
with "help" in the subject.

Trouble?  Email listmas...@chrony.tuxfamily.org.

Re: [chrony-users] Using gpsd

[Bill Unruh]

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 __|_theory.physics.ubc.ca/

On Tue, 19 Mar 2024, David Campbell wrote:


[CAUTION: Non-UBC Email]

I missed the "For example" bit, thanks for the clarification.

Reading the documentation again, I only can get the first example to work, so 
there
is no delay or offset.

# First option
refclock SOCK /var/run/chrony.ttyS0.sock refid GPS


On my system, /var/run is a link to /run. I think it was at least 5 years ago
that it was switeched from /var/run to /run



# Second option
refclock PPS /dev/pps0 lock NMEA refid GPS
refclock SOCK /var/run/chrony.clk.ttyS0.sock offset 0.5 delay 0.1 refid NMEA 
nosele
ct


That says that the system is .5 sec out? Hard to believe. Maybe you are using
the wrong part of the pulse (clear rather than assert?)

What makes you think you need the offset and delay set?


On 3/19/24 17:39, Bill Unruh wrote:

  On Tue, 19 Mar 2024, David Campbell wrote:

[CAUTION: Non-UBC Email]

  ...
Also, the device path given by chrony is out of date and
the one given by gpsd works: that is
"/run/chrony..sock" instead of
"/var/run/chrony.clk..sock". If I am wrong about the
paths, I don't know how chrony works, but only the former
works for me.


  man chrony.conf

    SOCK
     Unix domain socket driver. It is similar to the SHM
  driver, but
     samples are received from a Unix domain socket instead
  of shared
     memory and the messages have a different format. The
  parameter is the
     path to the socket, which chronyd creates on start. An
  advantage over
     the SHM driver is that SOCK does not require polling and
  it can
     receive PPS samples with incomplete time. The format of
  the messages
     is described in the refclock_sock.c file in the chrony
  source code.

     An application which supports the SOCK protocol is the
  gpsd daemon.
     The path where gpsd expects the socket to be created is
  described in
     the gpsd(8) man page. For example:

     refclock SOCK /var/run/chrony.ttyS0.sock

  See the words "For example:? Ie, the man page says to use what gpsd
  says the the
  path is.

  Note that path could well be different for different versions of Linux.

Re: [chrony-users] Using gpsd

[Bill Unruh]

On Tue, 19 Mar 2024, David Campbell wrote:


[CAUTION: Non-UBC Email]

...
Also, the device path given by chrony is out of date and the one given by 
gpsd works: that is "/run/chrony..sock" instead of 
"/var/run/chrony.clk..sock". If I am wrong about the paths, I don't know 
how chrony works, but only the former works for me.




man chrony.conf

  SOCK
   Unix domain socket driver. It is similar to the SHM driver, but
   samples are received from a Unix domain socket instead of shared
   memory and the messages have a different format. The parameter 
is the
   path to the socket, which chronyd creates on start. An advantage 
over
   the SHM driver is that SOCK does not require polling and it can
   receive PPS samples with incomplete time. The format of the 
messages
   is described in the refclock_sock.c file in the chrony source 
code.

   An application which supports the SOCK protocol is the gpsd 
daemon.
   The path where gpsd expects the socket to be created is 
described in
   the gpsd(8) man page. For example:

   refclock SOCK /var/run/chrony.ttyS0.sock

See the words "For example:? Ie, the man page says to use what gpsd says the the
path is.

Note that path could well be different for different versions of Linux.





--
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] ntptime returned error 5

[Bill Unruh]

Why would you use ntptime with chrony? They are different processes, and there
is no reason that chrony would impliment ntptime. ntptime is now about 40
years old. Why would you want to use it?

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 __|_theory.physics.ubc.ca/

On Wed, 3 Jan 2024, chengyechun wrote:


[CAUTION: Non-UBC Email]

Hi all

If chronyd is used as the local clock source, ntptime does not seem to work 
properly,
because of chrony's design or what configuration can control?

The following is the local configuration.

chronyd -p:

 

driftfile /var/lib/chrony/drift

makestep 1.0 3

rtcsync

allow all

local stratum 10

ntsdumpdir /var/lib/chrony

logdir /var/log/chrony

 

ntptime command output:

ntp_gettime() returns code 5 (ERROR)

  time e93f3fcd.1f79d000  Wed, Jan  3 2024 10:07:09.122, (.122952),

  maximum error 1600 us, estimated error 1600 us, TAI offset 0

ntp_adjtime() returns code 5 (ERROR)

  modes 0x0 (),

  offset 0.000 us, frequency 0.000 ppm, interval 1 s,

  maximum error 1600 us, estimated error 1600 us,

  status 0x40 (UNSYNC),

  time constant 3, precision 1.000 us, tolerance 500 ppm,

Re: [chrony-users] DNS/DKIM issue with tuxfamily.org?

[Bill Unruh]

I would not like it, if that is worth anything.

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 __|_theory.physics.ubc.ca/

On Tue, 12 Dec 2023, Miroslav Lichvar wrote:


[CAUTION: Non-UBC Email]

On Tue, Dec 12, 2023 at 01:50:17PM +, Joe Smith wrote:

Emails that I receive from tuxfamily.org for this group are being blocked by my 
organization, reportedly for security because of a failed DKIM lookup. My 
sysadmin indicated that the DKIM in DNS would need to be fixed. I tried sending 
an email to the tuxfamily.org admin a while back but got no response. I 
probably won't receive the responses to this if you respond to the group. 
Perhaps you can reply to me directly. I do apologize for this being off topic. 
I'd like to continue receiving these emails but can't if this DKIM issue isn't 
addressed. If any of you are able to look into this, it would be greatly 
appreciated. Thanks. Happy Holidays!


I think this was discussed before here. If tuxfamily is not willing to
fix it, there is not much we can do.

The mailing lists are unreliable. Some users get only some mails. It's
a general problem with mail. Spam broke it.

If there was a better provider for mailing lists for open source
projects, we could move. I'm not aware of any. I'm not interested in
running our own mail server.

We can also give up and switch all communication to web on gitlab. I
suspect many users wouldn't like that and the small community we have
here would be lost.

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




--
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] Improvement request: network status should not affect chronyc

[Bill Unruh]

Tell it to just use IP addresses. The delay is while it it trying to figure
out the name of the source from the IP address I believe. I believe there is
flag for the sources command to tell it not to use the DNS


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 __|_theory.physics.ubc.ca/

On Tue, 12 Dec 2023, Hollerer Franz, Schrack Seconet AG, Entwicklung wrote:


[CAUTION: Non-UBC Email]

I have an improvement request for chronyc, more precisely its sources command. I call 
"chronyc sources" via popen() from a C program to determine if the system time 
can be considered synchronized or not.

Unfortunately, if the network cable is disconnected, it takes about ~ 15 seconds for 
"chronyc sources" to complete. The initial connection to chronyd takes place 
immediately, also the header of the commands' output is print immediately. But then there 
is a very long delay till the line with the NTP server status is printed.

This means that the disconnected network cable has a non-negligible negative 
effect on the command line interface (CLI), although chronyd and chronyc run on 
the same host.

It would be nice if the network status would not affect chronyc, i.e., chronyc 
completes promptly.

Thanks

Franz Hollerer

--
To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org
with "unsubscribe" in the subject.
For help email chrony-users-requ...@chrony.tuxfamily.org
with "help" in the subject.
Trouble?  Email listmas...@chrony.tuxfamily.org.




--
To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org 
with "unsubscribe" in the subject.
For help email chrony-users-requ...@chrony.tuxfamily.org 
with "help" in the subject.

Trouble?  Email listmas...@chrony.tuxfamily.org.

Re: [chrony-users] How to Delay Chrony Start Until After PPS Device Attached

[Bill Unruh]

I have the following file in /etc/init.d and have systemd run it bootup.
note that it should not matter if the gps/pps unit is not attached at bootup--
it just means that ldattach sees no signals until it is.
But it would be better if it were attached always and chrony were started up
at bootup, as otherwise it could take a while for chrony to actually get the
clock into sync.

Also ups pps is not terribly accurate. UPS has no pps line. It had to get sent
as a ups message and then get converted to a signal by software ( which all
takes a while). Of course it depends on whataccuracy you want.



gps
--
#! /bin/sh
#
# gps Support for NTP serial gps clock. 
#

# chkconfig: 345 70 15
# description: gps is a module to read the PPS from a serial port
#
# 
# processname: gps


# Get config.
. /etc/sysconfig/network

# Get functions
. /etc/rc.d/init.d/functions

module="gps"
device="gps"
mode="664"
group=wheel

echo gsp $1 >>/tmp/gps

# See how we were called.
case "$1" in

start)
  echo "Starting gps pps service"
  modprobe pps-ldisc
  ldattach 18 /dev/ttyS0
 ;;

stop)
echo "Stopping gps pps service"
 killall ldattach
;;

status)
status ldattach
;;

restart)
$0 stop
$0 start
;;

*)
echo "gps wildcard">>/tmp/gps
gprintf "Usage: gps {start|stop|status|restart}\n "
exit 1
;;
esac

exit 0
--



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 __|_theory.physics.ubc.ca/

On Fri, 8 Dec 2023, Joshua Quesenberry wrote:


[CAUTION: Non-UBC Email]

Good Evening,

I'm pulling a 1PPS signal into my system over a USB to Serial device's
DCD pin; I don't have a typical RS232 port available. In order to fire
up the PPS line discipline on startup and to create a relably named
symlink to the created /dev/pps* (of which there are multiple
generated by PTP also) I'm using a combination of UDEV rules and a
pps_setup@.service service file. In my chrony.conf I'm giving it an
entry that looks for the PPS signal at the reliably named symlink (eg.
/dev/my_pps). The problem I'm running into now is that this device
isn't ready on startup before Chrony is started and therefore Chrony
is choking, so my hope is that some of you all have run into a similar
setup before and have recommendations on how to proceed? Is it
possible for me to set a couple second delay in starting Chrony to
give the device time to be available? Is there a way to make Chrony
not die and rather keep retrying to connect while continuing to use
other time sources in the interim? This would be ideal in case for
some reason the device never became available, such as being
accidentally unplugged.

Thanks!

Josh Q

--
To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org
with "unsubscribe" in the subject.
For help email chrony-users-requ...@chrony.tuxfamily.org
with "help" in the subject.
Trouble?  Email listmas...@chrony.tuxfamily.org.




--
To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org 
with "unsubscribe" in the subject.
For help email chrony-users-requ...@chrony.tuxfamily.org 
with "help" in the subject.

Trouble?  Email listmas...@chrony.tuxfamily.org.

Re: [chrony-users] Trouble running chronyd on old hardware

[Bill Unruh]

Why would you be running a 2.6 kernel? Is that really the newest kernet that
you hardware support?


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 __|_theory.physics.ubc.ca/

On Mon, 4 Dec 2023, Ahmed Habub wrote:


[CAUTION: Non-UBC Email]Hi Team, sorry for my bad English;

I'm trying to run chrony on a low-powered device, arm-926ejs CPU 400MHz and 
128MB of ram running Linux
2.6.31.4.26007 with Busybox slapped on top.

I managed to cross compile as I have a toolchain available to me, however, 
running chronyd on this device runs
with -dd and prints a couple of errors, then ends up in some sort of infinite 
loop.

Running within GDB (same happens inside or out):

# gdb --args chronyd -4 -n 'server time.cloudflare.com iburst' -dd
GNU gdb (GDB) 8.3.1
Copyright (C) 2019 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "arm-926ejs-linux-gnueabi".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
    .

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from chronyd...
(gdb) run
Starting program: /root/chronyd -4 -n server\ time.cloudflare.com\ iburst -dd
2023-11-29T10:01:20Z I:main.c:579:(main) chronyd version DEVELOPMENT starting 
(+CMDMON +NTP +REFCLOCK +RTC
-PRIVDROP -SCFILTER -SIGND -ASYNCDNS -NTS -SECHASH -IPV6 +DEBUG)
2023-11-29T10:01:20Z D:util.c:1419:(UTI_OpenFile) Opened 
/var/run/chrony/chronyd.pid fd=3 mode=r
2023-11-29T10:01:22Z D:util.c:1403:(UTI_OpenFile) Removed 
/var/run/chrony/chronyd.pid
2023-11-29T10:01:22Z D:util.c:1419:(UTI_OpenFile) Opened 
/var/run/chrony/chronyd.pid fd=3 mode=W
2023-11-29T10:01:22Z D:local.c:171:(LCL_Initialise) Clock precision 0.01879 
(-19)
2023-11-29T10:01:22Z D:sys_linux.c:294:(get_version_specific_details) Linux 
kernel major=2 minor=6 patch=31
2023-11-29T10:01:22Z D:sys_linux.c:321:(get_version_specific_details) hz=100 
nominal_tick=1
max_tick_bias=1000 tick_update_hz=2
2023-11-29T10:01:22Z D:local.c:683:(lcl_RegisterSystemDrivers) Local 
freq=-0.952ppm
2023-11-29T10:01:22Z D:socket.c:1511:(SCK_SetIntOption) setsockopt() failed 
fd=3 level=1 name=15 value=1 :
Protocol not available
2023-11-29T10:01:22Z D:socket.c:581:(open_ip_socket) Opened UDPv4 socket fd=3 
local=127.0.0.1:323
2023-11-29T10:01:22Z D:util.c:1419:(UTI_OpenFile) Opened /dev/urandom fd=4 
mode=R
2023-11-29T10:01:22Z W:main.c:656:(main) Running with root privileges
2023-11-29T10:01:22Z I:reference.c:240:(REF_Initialise) Initial frequency 
-0.952 ppm
2023-11-29T10:01:22Z D:clientlog.c:406:(CLG_Initialise) Max records 4096
2023-11-29T10:01:22Z D:socket.c:673:(open_unix_socket) Opened Unix socket fd=5
local=/var/run/chrony/chronyd.sock
2023-11-29T10:01:22Z D:ntp_sources.c:349:(log_source) Added source 
ID#01 (time.cloudflare.com)
2023-11-29T10:01:22Z D:ntp_sources.c:693:(resolve_sources) resolving 
time.cloudflare.com
2023-11-29T10:01:22Z D:ntp_sources.c:614:(name_resolve_handler) 
time.cloudflare.com resolved to 2 addrs
2023-11-29T10:01:22Z D:ntp_sources.c:553:(process_resolved_name) (1) 
162.159.200.123
2023-11-29T10:01:22Z D:socket.c:581:(open_ip_socket) Opened UDPv4 socket fd=6 
remote=162.159.200.123:123
local=0.0.0.0:0
2023-11-29T10:01:22Z D:socket.c:1511:(SCK_SetIntOption) setsockopt() failed 
fd=6 level=1 name=45 value=1 :
Protocol not available
2023-11-29T10:01:22Z D:ntp_sources.c:478:(change_source_address) Source 
ID#01 replaced with
162.159.200.123 (time.cloudflare.com)
2023-11-29T10:01:22Z D:ntp_core.c:1402:(transmit_timeout) Transmit timeout for 
162.159.200.123:123
2023-11-29T10:01:22Z D:socket.c:581:(open_ip_socket) Opened UDPv4 socket fd=6 
remote=162.159.200.123:123
local=0.0.0.0:0
2023-11-29T10:01:22Z D:socket.c:794:(log_message) Sent message fd=6 len=48
2023-11-29T10:01:22Z D:socket.c:733:(handle_recv_error) Could not receive 
message fd=6 : Function not
implemented
2023-11-29T10:01:22Z D:socket.c:733:(handle_recv_error) Could not receive 
message fd=6 : Function not
implemented
2023-11-29T10:01:22Z D:socket.c:733:(handle_recv_error) Could not receive 
message fd=6 : Function not
implemented
2023-11-29T10:01:22Z D:socket.c:733:(handle_recv_error) Could not receive 
message fd=6 : Function not
implemented
2023-11-29T10:01:22Z D:socket.c:733:(handle_recv_error) Could not receive 
message fd=6 : Function not
implemented
2023-11-29T10:01:22Z 

Re: [chrony-users] Chroy is taking long time detect PPS signal loss

[Bill Unruh]

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 __|_theory.physics.ubc.ca/

On Thu, 31 Aug 2023, Jatinder wrote:


[CAUTION: Non-UBC Email]Hello,

We are using Chrony for NTP and 1-pulse-per-second (1PPS) synchronisation. The 
system is able to
synchronize with NTP and PPS.
We observed one problem, when we remove PPS cable from the system Chrony is 
taking a long time to
detect it even after removal of PPS cable chronyc sources shows 
locked/synchronized.  


Of course. You would get very upset if it were to dump PPS it for some reason
only of the pulses were lost.  Your clock, corrected by chrony, is perfectly
capable to delivering very accurate time even if it misses a few pulses.
Instead of asking chrony to read your mind (I purposely disconnected it, can
chrony not read mind mind to know that) figure out what you really need, and
when you really want it to give up relying on the system clock. Remember that
chrony in default operation, will wait up to a hour between queries of the
network to keep the clock on time. 


System and configuration details:
We are using
https://www.variscite.com/product/system-on-module-som/cortex-a7/dart-6ul-freescale-imx-6ul/
 which
runs with Debian 10 and Kernel 4.14.170.
We are using the Kernel pps-gpio module to get a signal from a GPS receiver via 
GPIO pin.

Configuration in the Device-Tree:

pps@0 {
    compatible = "pps-gpio";
    pinctrl-0 = <_mux>;
    gpios = < 9 0>;
  };
               
pps_mux: pps_mux-1 {
         fsl,pins = ;
    };
               
Startup Kernel.log shows that pps0 is mapped with ptp0 and pps1 is mapped with 
1PPS input. with
/dev/pps and 1PPS is getting mapped to /dev/pps1
pps_core: LinuxPPS API ver. 1 registered
pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti 
giome...@linux.it
pps pps0: new PPS source ptp0
pps pps1: new PPS source pps@0.-1
pps pps1: Registered IRQ 222 as PPS source

We have two devices pps0 and pps1 under /dev. If we run ppstest on /dev/pps0 
and /dev/pps1, pps0
is not able to fetch anything but pps1 receives signal every second:  


Why would you want two sources?

It sounds like you have misconfigured pps0. Maybe you should give more details
of what you are doing. 


ppstest /dev/pps0
trying PPS source "/dev/pps0"
found PPS source "/dev/pps0"
ok, found 1 source(s), now start fetching data...
time_pps_fetch() error -1 (Connection timed out)

ppstest /dev/pps1
trying PPS source "/dev/pps1"
found PPS source "/dev/pps1"
ok, found 1 source(s), now start fetching data...
source 0 - assert 1693323647.99474, sequence: 58301 - clear  0.0, 
sequence: 0
source 0 - assert 1693323648.99022, sequence: 58302 - clear  0.0, 
sequence: 0
source 0 - assert 1693323649.99185, sequence: 58303 - clear  0.0, 
sequence: 0
source 0 - assert 1693323650.99395, sequence: 58304 - clear  0.0, 
sequence: 0
source 0 - assert 1693323651.99669, sequence: 58305 - clear  0.0, 
sequence: 0

cat /etc/chrony/chrony.conf
# Private GPS-sourced NTP servers have no polling abuse concerns.
# For this reason, setting minpoll/maxpoll to 0 (1 second) is allowed.
server 10.10.10.200 minpoll 0 maxpoll 0 maxdelay 0.5 iburst trust

# Location of ID/key pairs for NTP authentication.
keyfile /etc/chrony/chrony.keys

# Store new gain/loss rate, for compensating the system clock upon restart.
driftfile /var/lib/chrony/chrony.drift

# Enable logging of clock drift.
#log tracking measurements statistics
logdir /var/log/chrony

# Stop bad estimates upsetting machine clock.
maxupdateskew 100.0

# Enable kernel synchronisation (every 11 minutes) of the real-time clock.
rtcsync

# Use the real-time FIFO scheduler with the specified priority (between 0
# and 100). This results in reduced latency (extreme clock stability).
sched_priority 1

# Forcing more samples reduces noise in the estimated frequency and offset,
# but slows response to clock changes in the frequency and offset.
minsamples 32

# Step the system clock instead of slewing it if the adjustment is larger than
# one second, but only in the first three clock updates.
makestep 1 3

# Enable hardware timestamping of NTP packets for all interfaces.
hwtimestamp *

# Synchronize time using the rising edge of a 1-pulse-per-second clock.
refclock PPS /dev/pps1 refid PPS1 poll 0 precision 1e-9 prefer

This is when we removed/disconnected the PPS cable.  

date;chronyc sources
Mon 28 Aug 2023 09:24:36 PM UTC
210 Number of sources = 2
MS Name/IP address         Stratum Poll Reach LastRx Last sample
===
#* PPS1                          0   0   377     1   +881ns[ +932ns] +/- 1000ns
^- 10.10.10.200                  1   0   377     0    +28us[  +28us] +/- 1168us

This is when Chrony 

Re: [chrony-users] refclock local

[Bill Unruh]

It means that your PPS source is way out of line with the toher two sources
(half a second different) and thus is an outlier.It has small scatter ( 31us
rathee than the ms of the others).but still lies well outside the other two
sources.So chrony is not going to select it and feels that it is not to
betrusted.




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 __|_theory.physics.ubc.ca/

On Mon, 7 Aug 2023, Josef 'Jeff' Sipek wrote:


[CAUTION: Non-UBC Email]

I did an experiment tonight to see if I understood chrony's local refclock
support.

I connected a signal generator running at 1Hz to a serial-to-USB's CTS pin,
told the (FreeBSD) kernel to capture PPS pulses from that pin, and
configured chrony with (in addition to a handful of NTP servers):

refclock PPS /dev/cuaU1 local

I don't expect amazing results given that USB is involved, but I'm not sure
how to read the chronyc output to make sure that things are working.
'chronyc sources' lists the PPS source and it looks reasonable in general,
but I'm not sure what the '?' source state means.  Is chrony using the
source or is it ignoring it?

MS Name/IP address Stratum Poll Reach LastRx Last sample
===
#? PPS0  0   4   37713   -590ms[ -590ms] +/-   31us
^- kerberos.mit.edu  2   9   377   217   -171us[ -171us] +/-   25ms
^* time.cloudflare.com   3   8   377   917  -1018us[ -840us] +/- 8851us
...

'chronyc selectdata' is equally confusing - it looks like chrony correctly
marked the source as unsynchronized but there appears to be no data.  Is
that right?

S Name/IP AddressAuth COpts EOpts Last Score Interval  Leap
===
s PPS0  N - -0   1.0+0ns+0ns  ?
D kerberos.mit.edu  N -P--- -P---  404   1.0   -19ms   +18ms  N
* time.cloudflare.com   N -P--- -P--- 1103   1.0 -9124us +8298us  N
...

This is my first attempt at using chrony, so I might be missing something
obvious.

Thanks,

Jeff.

--
To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org
with "unsubscribe" in the subject.
For help email chrony-users-requ...@chrony.tuxfamily.org
with "help" in the subject.
Trouble?  Email listmas...@chrony.tuxfamily.org.




--
To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org 
with "unsubscribe" in the subject.
For help email chrony-users-requ...@chrony.tuxfamily.org 
with "help" in the subject.

Trouble?  Email listmas...@chrony.tuxfamily.org.

Re: [chrony-users] Measuring clock offset results

[Bill Unruh]

On Wed, 19 Jul 2023, Miroslav Lichvar wrote:


[CAUTION: Non-UBC Email]

On Wed, Jul 12, 2023 at 09:52:11AM -0700, Thangalin wrote:

https://ibb.co/album/1Z824p

Are there any other ways we could help chronyd stay below 20 microseconds
(e.g., optimized build) that may have been overlooked (besides using GPIO)?


If you zoom on those spikes and see that they are just single
samples, it's probably not an error of the clock, but rather a
measurement error (e.g. due to interrupt delays). You should implement
some filtering in your program, e.g. use the median value from a
number of consecutive samples (e.g. 5). That's what both ntpd and
chronyd are doing with the data they get.


Also you could eliminate one or 2 data points which are way off (say 2
standard deviations or two deviations ( Sum_i (|t_i-t_median|)/N) from the
median. Such events Mills calls popcorn events-- they are not gaussian
distributed  and are probably caused by single transient events (eg like
interrupt delays, or path delays (eg the routing algorithm suddenly sends a
packet from NY to Washington via Beijing for some unknown reason)).
So getting rid of such popcorn events can improve the signals a lot.




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




--
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] starting chronyd -q unreliable

[Bill Unruh]

On Mon, 10 Jul 2023, Calvin Arndt wrote:


[CAUTION: Non-UBC Email]

Thanks for reading and responding to my email Bill.

A little background.

While this server does belong to us, it was setup by a vendor and runs a very 
new centos knock off.

This vendors previous incarnations were all Centos 5, 6 and 7. Apparently 
something went BOOM in the Centos world


Apparently IBM/Redhat went BOOM and have refused to allow anyone who has not
bought Redhat to access any of the updates of the software. This sounds like
it is contrary to the GPL, but I guess that will take a while to work out in
the courts (either legal or public opinion).



and now I have a copy of "AlmaLinux release 8.6 (Sky Tiger)" I am neither 
impressed nor happy with it.

After about a year and a half running this server, I get this email:

[ Looks like the times are off in our POS system. 3:27 pm right now our POS 
system is saying 3:55 pm. Not a big deal
but if we need to prove something it might matter. ]

That was quite surprising to me! Centos being a well written RedHat knock off, 
comes preconfigured with a time
management solution. Looking around I find no time management solution installed. No 
biggie "yum install ntpdate"
should about do the trick. Imagine my surprise when I find no ntpdate package 
available! After some googling i find
this new kid on the block (chronyd) is available. So:


ntpdate is not a good procedure for setting clocks. It does not correct the
speed of the clock, and steps the clock. There is a flag to ntpd which allows
it to behave like ntpdate.



notmyserver:~# yum install chronyd

This is notmyserver and I'm not going to configure it for these people, so off to google 
to find an "update it now"
hack for chrony... 


I am really confused why you would want to use an ntpdate like hack for the
time control, instead of using either ntpd or chrony to continuously control
the clock, and give you way way better time accuracy. It is like running a car
(gasoline) without a flywheel. It is a horribly juddery and jerky ride. 


That's how I got to where I am.

What it appears to me that you've said, is that indeed, it is a bug, in chronyd 
since:

"set the system clock once and exit"

which it does not do every time, is a bug. 

Not sure why you mention "detach"

Since I don't start ssh with a controlling terminal, detaching shouldn't be an 
issue.

But maybe there's something going on there that you have a better grasp of than 
I.

Anyway by now I'm sure you've figured out that I'm a debian, ubuntu etc kind of 
user.

About the ntpdate comments. In all my 26ish years of running linux distros, I 
have never once ran up against

a bug in ntpdate. It has always worked for me. Why would anyone fix what isn't 
broken?


Because it is broken and has been since day 1. Its control of the clock is
terrible, and, if for some reason it stops working, the clock will run off
with a bad rate and rapidly be at the wrong time.  Chrony especially, will
have trimmed the clock so that both the time (offset) and the rate are as
close as possible to UTC.

Is there some reason why you cannot run chronyd  as a daemon, which constantly
adjusts both the rate and the offset to bring the system clock into sync with
UTC?



I did go back over all my chronyd emails.

In every instance of getting the msg:

2023-04-12T05:15:02Z Fatal error : Another chronyd may already be running

on the day prior chronyd reported that it had exited:

2023-04-11T05:15:08Z chronyd exiting


Lichvar mentions that that bug in chony has been fixed in recent versions.




Thanks again for your time!

Calvin


On 2023-07-07 12:28, Bill Unruh wrote:

  No idea really but the docs say
  -q
  When run in this mode, chronyd will set the system clock once and exit. 
It will not detach from the terminal.

  I would assume that if something gets in the way of setting the system 
clock
  once, then it will not detach. Eg your network goes downand it cannot run 
the
  burst command. But it seems to me that you are doing exactly what the 
chrony
  docs say you should not do-- namely trying to use that command to control 
your
  clock by running it every hour or something. It is silly and produces 
very suboptimal results. Someone
  probably set up the system to use ntpdate sometime in the 90's and now
  you are using that command to do the same thing 30 years later. Just let 
it
  run as a daemon. It does not take up a lot of space nor does it take up a 
lot
  of computing time.



  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 __|_theory.physics.ubc.ca/

  On Fri, 7 Jul 2023, Calvin Arndt wrote:

[CAUTION: Non-UBC Email]


chron

Re: [chrony-users] PPS GPIO polling driver license

[Bill Unruh]

So you are worried that if you write a non-GPL program which uses the pps
gpio, you will get sued for your own program being a derived work of PPS-gpio?

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 __|_theory.physics.ubc.ca/

On Fri, 7 Jul 2023, Thangalin wrote:


[CAUTION: Non-UBC Email]Thanks again, Bill.

> The SPDX seems to apply to the .h files associated with the driver, not the 
driver itself.
> Use of the driver by a program seems not to make the useing program a derived 
work,

This is also my understanding.

> so there is no need to have a special license.

Except the PPS GPIO poll source code isn't distributed _with_ the Linux kernel. 
That is, it isn't part of the kernel
repository. As such, I don't think it is safe to assume the Linux syscall 
exception applies to the source code.

> Perhaps if you told us why you are asking and what you want to do it would 
make it easier.

I have another post coming that'll provide more details of what I'm trying to 
accomplish. I'd prefer to keep this
thread on the topic of the license itself.

> What would you like the license to say?

It would be nice if the license made explicit reference to the Linux syscall 
exception. That is, being released
under SPDX GPL-2.0 with Linux-syscall-note.

Thanks again!




--
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] PPS GPIO polling driver license

[Bill Unruh]

I am probably confused. The SPDX seems to apply to the .h files associated
with the driver, not the driver itself. Use of the driver by a program seems
not to make the useing program a derived work, so there is no need to have a
special license. Perhaps if you told us whyyou are asking and what you want to
do it would make it easier. Of course I might be the only one confused. What
would you like the license to say?


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 __|_theory.physics.ubc.ca/

On Fri, 7 Jul 2023, Thangalin wrote:


[CAUTION: Non-UBC Email]Bill, the following file is a PPS driver distributed 
with the Linux kernel:

https://github.com/torvalds/linux/blob/master/drivers/pps/pps.c

It is also released under a GPL 2.0 license:

// SPDX-License-Identifier: GPL-2.0-or-later

However, being distributed with the Linux kernel, the source code falls under the 
"Linux with syscall exception"
clause, despite the source code comments only referring to GPL 2.

Does anyone know how to contact Gabriel Ricalde to see if re-licensing is 
permissible?

Thank you!




--
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] PPS GPIO polling driver license

[Bill Unruh]

Also the program itself states

"/*
 * pps-gpio-poll.c -- PPS client driver using GPIO (polling mode)
 *
 *   This program is free software; you can redistribute it and/or modify
 *   it under the terms of the GNU General Public License as published by
 *   the Free Software Foundation; either version 2 of the License, or
 *   (at your option) any later version.
 *
 *   This program is distributed in the hope that it will be useful,
 *   but WITHOUT ANY WARRANTY; without even the implied warranty of
 *   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 *   GNU General Public License for more details.
 *
 *   You should have received a copy of the GNU General Public License
 *   along with this program; if not, write to the Free Software
 *   Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
 */

 So why would it require an exception.


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 __|_theory.physics.ubc.ca/

On Fri, 7 Jul 2023, Thangalin wrote:


[CAUTION: Non-UBC Email]Hi,

Re: https://github.com/mlichvar/pps-gpio-poll

Does the driver fall under the Linux syscall note exception to the GPL?

https://github.com/torvalds/linux/blob/master/LICENSES/exceptions/Linux-syscall-note

If not, does anyone know whether there's a driver that does? Or falls under an 
MIT/Apache2/BSD license?

Thank you.





--
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] PPS GPIO polling driver license

[Bill Unruh]

It states that it is
"This is a continuation of the openwrt-stratum1 project by Gabs Ricalde."
which states that that project  falls under GPL v2



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 __|_theory.physics.ubc.ca/

On Fri, 7 Jul 2023, Thangalin wrote:


[CAUTION: Non-UBC Email]Hi,

Re: https://github.com/mlichvar/pps-gpio-poll

Does the driver fall under the Linux syscall note exception to the GPL?

https://github.com/torvalds/linux/blob/master/LICENSES/exceptions/Linux-syscall-note

If not, does anyone know whether there's a driver that does? Or falls under an 
MIT/Apache2/BSD license?

Thank you.





--
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] starting chronyd -q unreliable

[Bill Unruh]

No idea really but the docs say
-q
When run in this mode, chronyd will set the system clock once and exit. It will 
not detach from the terminal.

I would assume that if something gets in the way of setting the system clock
once, then it will not detach. Eg your network goes downand it cannot run the
burst command. But it seems to me that you are doing exactly what the chrony
docs say you should not do-- namely trying to use that command to control your
clock by running it every hour or something. It is silly and produces very suboptimal results. 
Someone probably set up the system to use ntpdate sometime in the 90's and now

you are using that command to do the same thing 30 years later. Just let it
run as a daemon. It does not take up a lot of space nor does it take up a lot
of computing time.



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 __|_theory.physics.ubc.ca/

On Fri, 7 Jul 2023, Calvin Arndt wrote:


[CAUTION: Non-UBC Email]


chronyd -q should perform requested operation then exit.
It should never stay running.
 
I start chrony daily via cron from another machine.
15 00 * * * ssh root@192.168.2.111 "chronyd -q 'pool pool.ntp.org iburst'"

This works for a while...

2023-06-07T05:15:01Z chronyd version 4.2 starting (+CMDMON +NTP +REFCLOCK +RTC 
+PRIVDROP +SCFILTER +SIGND +ASYNCDNS
+NTS +SECHASH +IPV6 +DEBUG)
2023-06-07T05:15:01Z Initial frequency -12.651 ppm
2023-06-07T05:15:06Z System clock wrong by -0.001617 seconds (step)
2023-06-07T05:15:06Z chronyd exiting

Then for seemingly no reason:

2023-07-06T05:15:01Z chronyd version 4.2 starting (+CMDMON +NTP +REFCLOCK +RTC 
+PRIVDROP +SCFILTER +SIGND +ASYNCDNS
+NTS +SECHASH +IPV6 +DEBUG)
2023-07-06T05:15:01Z Fatal error : Another chronyd may already be running 
(pid=1141), check /run/chrony/chronyd.pid

So I start killing it an hour before via cron.
14 00 * * * ssh root@192.168.2.111 "kill `pidof chronyd`| -v 'usage:'"

This works fine for a month or so and then wala its back again.
This should never happen.

Affected machine is a centos clone distro.
--
 Calvin Arndt
(217) 377-2979
car...@macksrecycling.com

Re: [chrony-users] Chrony not taking SOCKET data from Application

[Bill Unruh]

Why would you be using makestep if the difference were more than 100ns. That
both seems extreme and totally subverts the action of chrony. Chrony is
designed to correct the system clock to the best estimate of the true time and
rate. Makestep ruins that, especially the rate estimate. Nothing can control
the clock to 100ns unless you have very special hardware. 100ns is less than
100 ft of cable, and needs very special impedance matching to attain.


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 __|_theory.physics.ubc.ca/

On Wed, 28 Jun 2023, sarveshwar k wrote:


[CAUTION: Non-UBC Email]Hi Miroslav,
> Verify that the process which syncs the system clock on start from the
> external RTC doesn't do that again later. Other than that I have no
> idea what could be wrong.
System time is updated with RTC once and when 3D fix is received, system time 
is corrected to GPS time
using Chronyd (as I am sending the GPS time using Unix Domain Socket to chrony. 
Chronyd uses PPS as a
trusted source).
The chronyc sources output shows large offset in milliseconds during the first 
3 samples.

One clarification on another item related to Chronyd:
- I am using the makestep directive (which does continuously if the difference 
is more than 100ns) in the
config file. Does chronyd adjusting the system time affects the CLOCK_MONOTONIC 
as well? 

Thanks & Regards
Sarveshwar.K

On Tue, May 9, 2023 at 12:45 PM Miroslav Lichvar  wrote:
  On Mon, May 08, 2023 at 12:09:16PM +0530, sarveshwar k wrote:
  > Hi Miroslav,
  >
  > My Implementation is as below:
  > - We have external RTC, which is used to sync system time on 
initialization
  > based on 1PPS from external RTC
  > - And on receiving GNSS 3D fix, the GPS UTC time is sent to chrony over
  > Unix Domain Socket.
  > - And we sync RTC for every 10 seconds on GNSS 1PPS (so that RTC is 
close
  > to the UTC time in seconds)

  > Can you please support on debugging what can be the issue.

  Verify that the process which syncs the system clock on start from the
  external RTC doesn't do that again later. Other than that I have no
  idea what could be wrong.

  --
  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] Searching for reasoning on design decisions

[Bill Unruh]

rony was designed by Curnoe. He finally gave up about 10 years ago and Lichvar
took it over, but did not change the design.chrony uses a least squares fit,
with an estimator as to how well the LSF actually fits the data, and
withdrawing the older points until it does fit. (eg if there were a strong
second order curve to the data, as evidenced by the LSF having long stretches
of errors from the linear curve of the same sign, it reduces the length of
time over which the LSF is applied. NPTD does a local, essentially Markovian
estimator.for the offset and the rate. Mills argues that he spent time making
sure that his approach was stable. The same degree of formal testing has not
been applied to chrony, however, all tests in a real life shows that chrony is
a) stable, and b) is usually far more accurate (smaller deviation of the
offsets and better estimation of the rate)  than is NTPD.

In both cases the code is essentially the documentation.

While chrony uses a linear estimator, the pruning of the points used in making
the estimates is non-linear.



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 __|_theory.physics.ubc.ca/

On Tue, 27 Jun 2023, Marc Compere wrote:


[CAUTION: Non-UBC Email]
This sounds pretty interesting Julian. 

You’re asking great questions and I’d like to know the answers as well. 

Miroslav Lichvar is probably the best source for recent and perhaps even prior 
design choices.

Marc



__
From: Julian Steinmann 
Sent: Tuesday, June 27, 2023 3:28 PM
To: chrony-users@chrony.tuxfamily.org 
Subject: [chrony-users] Searching for reasoning on design decisions  
Hi,

I'm a bachelor student at ETH Zurich and am currently working on my
bachelor thesis, which is about helping in implementing a new clock
synchronisation approach called G-SINC.
G-SINC (https://github.com/marcfrei/scion-time, paper linked in README)
focuses especially on byzantine fault-tolerance and builds on a new
internet architecture called SCION.

Right now I am focusing on implementing the sample offset interpolation
algorithm. We have already implemented a PLL-based algorithm, taken from
Ntimed by Poul-Henning Kamp and are exploring an approach using the
Theil-Sen estimator, but are also looking at re-implementing the
existing algorithms in chrony and ntpd.
In all of this, chrony is basically our "gold standard" when it comes to
accuracy and design approaches.
However, I haven't found much reasoning why e.g. weighted linear
regression is used in chrony for NTP samples, whilst a robust linear
regression (Least Absolute Deviations) is used for RTC samples and
manual input (I hope I'm not mistaken in my reading of the code).

Is there some place where these design decisions are justified? For
ntpd, there is of course the Computer Network Time Synchronisation book,
but David L. Mills seems to reach different conclusions than chrony does...
I hope I haven't overlooked some obvious place to search; otherwise, I'm
very sorry for bothering the list.

Best regards,
Julian


--
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] Accurately measuring clock drift

[Bill Unruh]

Why do you care what the lengthof th epulse is? The time is the in the
transition not in the length of the pulse. To reduce that error you wnat to
make sure that you use Impedence matching in cable connecting the gps receiver
to the computer.That aloso means that you power supply needs to handle
relatively high currents, since the cable impedance tends to be low ( 50 ohm,
300 ohom, the forver would require a pulse current of .1Amp).

But that assumes you do not want the pusle rise smeared out from its few
nanosecond rise time  at the gps receiver.

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 __|_theory.physics.ubc.ca/

On Wed, 21 Jun 2023, Rob Janssen wrote:


[CAUTION: Non-UBC Email]

Miroslav,

Are you aware of any affordable PCIe card that supports PPS input on a generic 
PC server?

Ideally would be like this:

- TTL input of a PPS signal with minimal pulse length all the way down to 100ns
- some hardware time stamping method
- supported interface to chrony
- maybe even a serial port in addition

That would be ideal to interface an external GPSDO to a Linux server with best 
accuracy,
like for simulcasting.  We could use a couple of these in our network...  it 
would work better
than the RS232 DCD input that we use now, avoid the need for a "pulse 
stretcher" as is
now required with some types of GPSDO, and custom cables to feed the signal in 
the RS232
port that is already used for many purposes.

It seems like something that could be easily designed, but of course any 
low-volume PCIe
card tends to be quite expensive...  and cards from the well known 
manufacturers in this
field are way outside our budget.

Rob

--
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] Accurately measuring clock drift

[Bill Unruh]

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 __|_theory.physics.ubc.ca/

On Tue, 20 Jun 2023, Thangalin wrote:


[CAUTION: Non-UBC Email]Thank you, Miroslav, that helps.

  That depends on the hardware. There might be a better way to timestamp
  the PPS that doesn't involve interrupts. Is it an x86_64 machine?
  See these two examples:


It's armv7l running kernel 4.14 with chrony 3.4. The 1PPS signal comes from an 
Orolia SecureSync
1200-313(https://safran-navigation-timing.com/wp-content/uploads/2021/07/SecureSync_UserRefGuide_PN_1200-5000
-0050_r31-1.pdf).

What we're trying to do is find a way to confirm whether switching from NTP to 
chrony will give us
less clock drift. Based on our measurements (my aforementioned graphs), it 
looks like switching from
NTP to chrony has made the clock drift worse. This doesn't make sense to me 
because chrony is known
for providing significant improvements upon NTP, and we're polling at 1-second 
intervals.




How would you go about measuring the clock drift between NTP and chrony so as 
to verify the drift has


It is not the clock drift-- that is averave rate at which the clockticks
faster or slower than UTC. It is not the offset between the system time and
the pps time. That can jump around for all kins of reasons-- interrupt delays,
other programs delaying the reading ofthe system clock, etc.


been reduced? I thought using the estimated error would provide a good 
indicator, but since it's not
an apples-to-apples comparison, what alternatives are available?


You can have three machines all getting data from each other, without using
that data to disciplin the system clock.


Aside, is there anywhere in particular in the chronyc sources we should look?


You could tell us why you want to do what you say you want to do.



Thank you!
 

  
https://chrony.tuxfamily.org/examples.html#_server_using_reference_clock_on_serial_port
  
https://chrony.tuxfamily.org/examples.html#_server_using_reference_clock_on_nic

  >    - How can we verify that the clock isn't drifting more than 30 μs,
  >    programatically (i.e., what API calls return the recent clock drift
  >    adjustment value)?

  I don't think that is possible without a more accurate time source.

  >    - What API call returns the most recent clock drift adjustment value 
in
  >    nanoseconds?

  This information is not available in the kernel (adjtimex). You would
  need to use chronyc sources.

Re: [chrony-users] chrony not switching to stratum 10 after loss of references

[Bill Unruh]

The  local time is the time on your compter. So you want to set the time on
your computer to itself. Not a very useful thing to do. There is not some
maging clock. Chrony will keep reporting its own time as long as its estimate
of the error in your local time is small enoght. Why not? It has spent much
time getting the local erros down, but fitting to to tfind the offset and the
rate of the local clock. So many people decide to test by sutting off all
imput, and expectingchrony to do something weid to allevate the problem. Trust
that the designers of chrony have thought about what to do in that case and to
try to delive the best time they can, even in that situation. (and using the
local clock to set itself is almost never the best solution, since that throws
awy all of the work it has done fguring out what the best parameters are to
keep the local clock on track for a long time).

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 __|_theory.physics.ubc.ca/

On Wed, 14 Jun 2023, Charbonneau, André wrote:


[CAUTION: Non-UBC Email]

Hi,

 

I’m having a problem with a system configured as a stratum 1 NTP server, 
running chrony, and I can’t
seem to be able to figure out what is happening and what might be the root 
cause of the problem.

(details about the setup are at the end of this message)

 

 

Basically, my stratum 1 servers takes a 1PPS and NMEA timecode on a serial 
port.  It also runs gpsd. 
I’ve configured the SHM references as such in /etc/chrony.conf:

 

# Configure NMEA + 1PPS via shared memory:

refclock SHM 0 refid NMEA precision 1e-1 offset 0.000109

refclock SHM 1 refid PPS offset 0.0 precision 1e-7

<… snip …>

local stratum 10

 

With this configuration, chrony is happy, sees the 2 signals (e.g., reach of 
377 on each) and serves
time as a stratum 1 server.  All good so far.

 

 

 

But then I intentionally stop the 1PPS and timecode signals to simulate a 
failure of the upstream
reference.  Because of the “local stratum 10”, I was expecting chrony to switch 
stratum 10
automatically when the reach value reaches 0 on those 2 references, but this is 
definitely not what
I’m seeing.

 

Instead, it seems like chrony continues to be a stratum 1, long after the 
reference signal have been
terminated. 

For example, the chrony sources and tracking command output below was taken 
approx. 1 hour after
termination of 1PPS and NMEA signal:

 

$ sudo date; sudo chronyc sources; sudo chronyc tracking

Wed Jun 14 08:23:00 PM UTC 2023

MS Name/IP address Stratum Poll Reach LastRx Last sample  

===

#? NMEA  0   4 0   57m    -93us[  -93us] +/-  100ms

#? PPS   0   4 0   57m    +98ns[ +346ns] +/-  101ns

Reference ID    : 50505300 (PPS)

Stratum : 1

Ref time (UTC)  : Wed Jun 14 19:25:50 2023

System time : 0.00041 seconds fast of NTP time

Last offset : +0.00256 seconds

RMS offset  : 0.00151 seconds

Frequency   : 12.835 ppm fast

Residual freq   : +0.006 ppm

Skew    : 0.008 ppm

Root delay  : 0.1 seconds

Root dispersion : 0.003475379 seconds

Update interval : 16.0 seconds

Leap status : Normal

 

I’ve also confirmed that it still happily serves time at stratum 1 level if I 
query it from another
system (using ntpdate tool for example from another system). 

 

Is this normal and expected?  I was expecting chrony to fallback to stratum 10 
but this is not what is
happening.

 

There is probably something obvious I’m missing in my chrony.conf file to 
implement the desired
behavior but I’m not able to figure it out.

 

Anyone else experienced this before?

 

 

System and setup info:

 

HP EliteDesk 800 G2 SFF

chrony version 4.3

gpsd 3.23.1-1.el9

AlmaLinux release 9.2 (Turquoise Kodkod)

Linux 5.14.0-284.11.1.el9_2.x86_64 #1 SMP PREEMPT_DYNAMIC Tue May 9 05:49:00 
EDT 2023 x86_64 x86_64
x86_64 GNU/Linux

 

chrony.conf:

 

refclock SHM 0 refid NMEA precision 1e-1 offset 0.000109

refclock SHM 1 refid PPS offset 0.0 precision 1e-7

driftfile /var/lib/chrony/drift

leapsecmode system

makestep 1.0 3

rtcsync

hwtimestamp *

minsources 1

allow ***.***.0.0/16

local stratum 10

logdir /var/log/chrony

log measurements statistics tracking refclocks tempcomp

 

 

 

 

Any information or insights about this would be much appreciated.

 

Thanks,

  Andre

 

 

--

Andre Charbonneau

 

Frequency & Time

Metrology Research Centre

National Research Council Canada / Government of Canada

andre.charbonn...@nrc-cnrc.gc.ca / 613-993-3129

 

Fréquence et temps

Centre de recherche en métrologie

Conseil national de recherches Canada / Gouvernement du Canada

Re: [chrony-users] PPS and NMEA same source not combined

[Bill Unruh]

Well, not at the offsets but the offsets and the statistical standard
deviation. and also depends on the number of sources. There is a voting system
in place as well. That is why one should always have an odd number of sources,
so "good ones" can outvote "bad ones". 
The PPS offset and spread will (almost) always be within the spread of the

internet sources, but the NMEA could well be outside because of systematic
errors. It will tend to have large spread because of the variability of
getting its sentences out. But the PPS should have a very small spread (micro
to namnoseconds) and lie within the spread of the internet sources (unless
your internet connection is very assymmetric).

Doing this made me look at mine and discover that the PPS source seems to have
died yesterday. Thanks.


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 __|_theory.physics.ubc.ca/

On Sun, 19 Mar 2023, Rob Janssen wrote:


[CAUTION: Non-UBC Email]

True, but an NMEA source is not an accurate local source.  A PPS source is.
So the hierarchy is:
1 - PPS source
2 - internet source(s)
3 - NMEA source

And chrony correctly determines that, after looking at the reported offsets.

On 3/19/23 21:00, Mike Smith wrote:

Rob,
Yes I kind of understand your thinking and I was about to agree but surely if 
you have a more accurate local source, using that would be preferable?
Mike.



--
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] PPS and NMEA same source not combined

[Bill Unruh]

Actually offset not drift (Offset is the actual time difference between your
clock and the true time, drift is the rate at which the offset grows, or
shrinks.

Anyway that is a very minor point. It sounds to me that your nmea is not
working at all, which is why I was asking how you deliver the nmea time to
chrony. 
What is your /etc/chrony.conf file? Ie, could you show us a copy of your

chrony.conf file?


What does (run as root)
chronyc
sources
actually say? (Ie show us a copy and paste of the output of the sources
output.)



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 __|_theory.physics.ubc.ca/

On Sun, 19 Mar 2023, Mike Smith wrote:


[CAUTION: Non-UBC Email] Bill thanks for explanation of the 300ns, all very 
clear and no I don’t need
it, it’s an interesting exercise however. :)
My pps and NMEA both come from a gps hat (u-blox M8Q). 

When I found the mega drift I did restart chrony which in effect did nothing to 
the drift.  So on the
surface it seems to me that NMEA is looking at the second and pps looking at 
sub second, which did
surprise me a little as I would have expected the NMEA to cover the broadest 
time and date first
before narrowing down on the second, hence my original question.  
In order to get it all back in sync I had to set the date and then restart 
chronyd, which shortly
after resulted in a corrected time.  At no point did chronyc sources show me 
any errors, all very odd.

Thanks for you time and explanations Bill you have help me understand this a 
lot more that I did a few
days ago.  

Mike
 

Kind regards, Michael A Smith.


 m...@realtimetesting.co.uk
My apologies for any incorrect information or typographical errors. Any 
opinions expressed are my own,
and are not intended to offend. Anyone offended by anything stated, will likely 
have offended me, by
being inconsiderate of my beliefs.
 

  On 19 Mar 2023, at 17:26, Bill Unruh  wrote:

  Whetehr it is actually accurate to 300ns is open to debate. It has no 
way of
  knowing what the time lag is between the GPS receiver receiving the second
  mark, and the computer actually registring it. Length of the cable from 
the
  receiver to the computer, time of the computer actually registring the 
arrival
  of the leading edge of the pulse. Time required to actually read the 
system
  clock. Those are all places of systematic delays. All chrony can do is to
  measure the random delays and errors, and average them out. That gives the
  300ns. Without another more accurate timing source you cannot test the
  actually accuracy. But I suspect you do not care for that kind of accuracy
  anyway.

  Secondly, are you sure that your nmea actaully works and is delivering the
  time to the computer?If you stop and restart chrony is the time delivered
  approximately right? If you look in the chrony logs, do you see the nmea 
time
  being delivered to the machine even if it is not selected?

  So what does it say
  chronyd
  sources

  How are you getting the nmea timing?


  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 __|_    theory.physics.ubc.ca/

  On Sun, 19 Mar 2023, Mike Smith wrote:

[CAUTION: Non-UBC Email] Well in theory no one has access apart 
from me, but
yesterday after I was messing about with it, trying to

get it all working.  Then I looked in more detail PPS working 
within 300ns
wow! but then I looked at the time and date and it was in

July 2022.  So it was accurate to the second but way out in time 
and date,
rather surprised me.  Was all very odd.

 

[t_7edvEm.jpg?v=45]

Kind regards, Michael A Smith.

 07973 221971

 24, Fifth Avenue, Portsmouth PO6 3PE UK

 m...@realtimetesting.co.uk

My apologies for any incorrect information or typographical errors. 
Any
opinions expressed are my own, and are not intended to

offend. Anyone offended by anything stated, will likely have 
offended me, by
being inconsiderate of my beliefs.

 


 On 19 Mar 2023, at 16:22, Bill Unruh  
wrote:


 On Sun, 19 Mar 2023, Mike Smith wrote:


   [CAUTION: Non-UBC Email] Ok Bill thanks very much for the
comprehensive reply, so in effect I am using


   both effectively by locking my pps against an NMEA, and 
once it has
that pps takes over and NMEA

Re: [chrony-users] PPS and NMEA same source not combined

[Bill Unruh]

NMEA is in general a terrible clock, unless what you want to know is "What 
second is the time at". Delivering an NMEA string takes about 1/10 of a 
second. 9600Bd, with 10 bits per character, and about 100 characters per string.

Compare that to PPS which delivers the "top of the second" to about 1
microsecond, 10 times better. Ie, nmea and pps are completely
incomparable. The NMEA is of course critical in telling which second it was
that tht PPPS pulse was telling you to the microsecond when it occured. YOu
can tell PPS to use NMEA to find out what second it is (it could also use
almost any other source on the net as well, but once it has done so, it no
longer needs it unless something disasterous happens so that chrony no longer
know what second the signal came in on (eg the computer shut down for an hour
or more).



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 __|_theory.physics.ubc.ca/

On Sat, 18 Mar 2023, Mike Smith wrote:


[CAUTION: Non-UBC Email] Hi, I have a GPS hat working fine with a steady nice 
long stream of sats.
My chrony conf file has the following refclocks 

refclock PPS /dev/pps0 lock nmea refid PPS
refclock SHM 0 refid NMEA

Chrony eventually chooses my PPS as the current best clock as I would have 
expected.  Unfortunately the NMEA clock always comes up
with the ? Maybe in error when queried from chronyc sources

I can’t see why NMEA should be in error when it’s essentially the same source.  
Is there something I can do to keep pps as current
best clock and NMEA to be combined?

Sorry if it’s a stupid question

Thanks, Mike.


 

Kind regards, Michael A Smith.



 m...@realtimetesting.co.uk
My apologies for any incorrect information or typographical errors. Any 
opinions expressed are my own, and are not intended to
offend. Anyone offended by anything stated, will likely have offended me, by 
being inconsiderate of my beliefs.
 

Re: [chrony-users] Chrony not taking SOCKET data from Application

[Bill Unruh]

AFAIK , rtcsync syncs the rtc clock to the system clock when the rtcsync
directive is given. It is not a continuous process. chrony itself measures the
offset and drift of the rtc and remembers them when next it is asked to set
the system clock from the rtc. That assumes that nothing else has altered the
rtc, and that the temperature of the rtc has been constant, because its drift
is strongly influenced by temperature. There is aslo the keernel 11 min sysnc,
where the kernel every 11 min can reset the rtc from the system clock. In that
case measuring the drift does not work.

The problem with chrony's use of the rtc drift is precisely the temperature
dependence. That drift is measured while the computer is running and thus warm. 
But it is
usually used after the computer has been off and thus cold. (and unfortunately
the computer cannot take that into account since it is not running or
measuring anything while it is off). 
But anyway, chrony uses the rtc only on switchon. It does not use it at other

times.

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 __|_theory.physics.ubc.ca/

On Mon, 13 Mar 2023, sarveshwar k wrote:


[CAUTION: Non-UBC Email]Hi Miroslav Lichvar,
Does "rtcsync" directive starts syncing RTC with system time irrespective of 
refclocks syncing the
System clock.


No, rtcsync does a one time sysnc of the rtc with system time.



Can we configure as like below:
1. Using refclocks for GPS and PPS, sync the system clock
2. Once system clock is synced, RTC should be synced
3. If no refclock signals available for GPS and PPS, rtcsync shall not happen

Thanks & Regards
Sarveshwar.K

On Fri, Feb 24, 2023 at 10:37 AM Bill Unruh  wrote:

  On Fri, 24 Feb 2023, sarveshwar k wrote:

  > [CAUTION: Non-UBC Email]Hi Miroslav Lichvar,
  > Can I use pps directive to a PPS refclock?
  > refclock PPS /dev/pps1 poll 0 pps lock GPS refid PPS trust prefer
  >
  > Will this increase the accuracy?


No.


  >
  > I am using below refclocks:
  > refclock PPS /dev/pps1 poll 0 lock GPS refid PPS trust prefer
  > refclock SOCK /var/run/chrony/udssocket.sock poll 0 refid GPS noselect

  It is not going to poll at GHz rates (that is the speed of the computer) 
I am
  not sure but suspect polling would be better, but could also be more 
subject
  to delays if the computer is busy. Do not know if anyone has compared 
polling
  to interrupt.

  >
  > As we are using GPS and 1PPS, our assumption is chrony synchronizes 
system clock with
  nanosecond
  > level accuracy. Am I right on this? But we see microsecond level 
accuracy even after
  using
  > makestep directive.

  No. It cannot. The clock does not even send out the PPS with ns accuracy. 
Most
  gps receivers put out a pps signal which is a sawtooth accuracy of tens 
of ns
  displacement which can be corrected later, if you have a timeing gps.
  Furthermore one needs to set up the PPS cabling so as to impedence match
  between the gps receiver, the cabling and the computer interface. or the 
pps
  edge will get rounded off and smeared out with an unknown relation to the
  actual time to probably hundreds of nanoseconds. Futher more the computer 
has
  to notice that the pulse has come in and to read the system clock which 
is of
  the order of a microsecond. Now if you had a super accurate clock that you
  could compare the computer time with the UPS time, then some of that 
error is
  systematic and could be subtraced off. The random fluctuation can be 
averaged
  out in chrony to maybe 100ns, but of course systematic errors cannot be
  averaged out. So you are probably goot to a microsecond, not nanoseconds.

  >
  > Thanks & Regards
  > Sarveshwar.K
  >
  > On Mon, Feb 20, 2023 at 3:56 PM sarveshwar k  
wrote:
  >       Hi Miroslav,
  > Thanks for the information.
  >
  > >My question would be, why do you need the system clock to be so
  > >accurate? The CPU is connected to the outside world over PCIe, which
  > >has latency and possibly also asymmetry in hundreds of nanoseconds.
  > >What do you do on that computer that this accuracy would make a
  > >difference?
  > This system clock is being used by other applications like IMU sensor 
data
  timestamping. 
  > We are having this chrony running in an ECU (Electronic Control Unit) 
along with PTP
  stack
  > to send PTP packets to other ECUs in the network to get synced to 
Master ECU.
  >
  > Thanks & Regards
  > Sarveshwar.K
  >

Re: [chrony-users] Chrony not taking SOCKET data from Application

[Bill Unruh]

On Fri, 24 Feb 2023, sarveshwar k wrote:


[CAUTION: Non-UBC Email]Hi Miroslav Lichvar,
Can I use pps directive to a PPS refclock?
refclock PPS /dev/pps1 poll 0 pps lock GPS refid PPS trust prefer

Will this increase the accuracy?

I am using below refclocks:
refclock PPS /dev/pps1 poll 0 lock GPS refid PPS trust prefer
refclock SOCK /var/run/chrony/udssocket.sock poll 0 refid GPS noselect


It is not going to poll at GHz rates (that is the speed of the computer) I am
not sure but suspect polling would be better, but could also be more subject
to delays if the computer is busy. Do not know if anyone has compared polling
to interrupt.



As we are using GPS and 1PPS, our assumption is chrony synchronizes system 
clock with nanosecond
level accuracy. Am I right on this? But we see microsecond level accuracy even 
after using
makestep directive.


No. It cannot. The clock does not even send out the PPS with ns accuracy. Most
gps receivers put out a pps signal which is a sawtooth accuracy of tens of ns
displacement which can be corrected later, if you have a timeing gps. 
Furthermore one needs to set up the PPS cabling so as to impedence match

between the gps receiver, the cabling and the computer interface. or the pps
edge will get rounded off and smeared out with an unknown relation to the
actual time to probably hundreds of nanoseconds. Futher more the computer has
to notice that the pulse has come in and to read the system clock which is of
the order of a microsecond. Now if you had a super accurate clock that you
could compare the computer time with the UPS time, then some of that error is
systematic and could be subtraced off. The random fluctuation can be averaged
out in chrony to maybe 100ns, but of course systematic errors cannot be
averaged out. So you are probably goot to a microsecond, not nanoseconds.



Thanks & Regards
Sarveshwar.K

On Mon, Feb 20, 2023 at 3:56 PM sarveshwar k  wrote:
  Hi Miroslav,
Thanks for the information.

>My question would be, why do you need the system clock to be so
>accurate? The CPU is connected to the outside world over PCIe, which
>has latency and possibly also asymmetry in hundreds of nanoseconds.
>What do you do on that computer that this accuracy would make a
>difference?
This system clock is being used by other applications like IMU sensor data 
timestamping. 
We are having this chrony running in an ECU (Electronic Control Unit) along 
with PTP stack
to send PTP packets to other ECUs in the network to get synced to Master ECU.

Thanks & Regards
Sarveshwar.K

On Thu, Feb 16, 2023 at 1:59 PM Miroslav Lichvar  wrote:
  On Thu, Feb 16, 2023 at 10:04:02AM +0530, sarveshwar k wrote:
  > Is it not possible to achieve synchronization accuracy less than 100ns 
with
  > chrony (with GPS and 1PPS).

  With HW timestamping of the PPS signal (e.g. on the I210) it is
  possible, but difficult to verify.

  My question would be, why do you need the system clock to be so
  accurate? The CPU is connected to the outside world over PCIe, which
  has latency and possibly also asymmetry in hundreds of nanoseconds.
  What do you do on that computer that this accuracy would make a
  difference?

  > Can we configure chrony behaving as a measurement tool (not to make any
  > corrections)?

  There is the chronyd -x option or the refclock noselect option for
  that.

  --
  Miroslav Lichvar


  --
  To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org
  with "unsubscribe" in the subject.
  For help email chrony-users-requ...@chrony.tuxfamily.org
  with "help" in the subject.
  Trouble?  Email listmas...@chrony.tuxfamily.org.

Re: [chrony-users] Chrony not taking SOCKET data from Application

[Bill Unruh]

I do not know what your setup is, but the problem is that the getting the
signal from the gps receiver, having it trigger an interrupt, then reading the
computer clock takes a while. A number of years ago when I tested this, it
took about 1 microsecond to carry all that out. That means that 100ns is
pretty tough without some sophisticated hardware, and without very careful
wiring . The antenna to the GPS receover and the signal from the gps to the
computer can easily smear out the edge of the signal to worse than 100ns.
Often that might be repeatable, and thus the variance of the time may be at
the 100ns level but the difference in time between true GPS time and the
computr clock could be out by a microsecond or more. Of course if you knew
what that was then you could subtract it, but how are you going to know?

So, yes, it is possible but hard.

I am not sure what you mean by using chrony as a measurement tool. Its memory
is the system clock. It does not have some other internal clock. It gets a
pulse at once per sec, it needs to compare that with a clock. 
You remember about 10 years ago a news flash came out that they had measured

the velocity of neutrinos and discovered it was faster than light. It
eventually turned out that there was a bad connection in the fibre optics link
from the gps antenna to the system, which smeared out the rising edge of
the pulse to make it late. Thus the time difference between receipt of the
neutrino and emission was too short, implying a faster speed.
Remember that 100ns is 100 ft of travel (30m of travel). That is not much.

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 __|_theory.physics.ubc.ca/

On Thu, 16 Feb 2023, sarveshwar k wrote:


[CAUTION: Non-UBC Email]Hi Miroslav Lichvar,
Can you please provide below information:
Is it not possible to achieve synchronization accuracy less than 100ns with 
chrony (with GPS and
1PPS).
Can we configure chrony behaving as a measurement tool (not to make any 
corrections)?

Thanks & Regards
Sarveshwar.K

On Tue, Feb 7, 2023 at 2:05 PM Miroslav Lichvar  wrote:
  On Tue, Feb 07, 2023 at 12:04:53PM +0530, sarveshwar k wrote:
  > > The reason for chronyc sources sometimes showing 2 as LastRx, even
  > > when no samples are lost, seems to be incorrect rounding of the sample
  > > time. I can fix that.
  >
  > Will there be a release for this fix.
  > Current version I am using is 3.5 of chrony for which yocto recipe 
exists.

  It will be in the next release. Backport the commit dec07aa844f8 from
  the chrony repository to 3.5 shouldn't be too difficult. It's not
  actually a bug, but rather a data-minimization feature which is not
  necessary for reference clocks.

  --
  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] Strange "loss of PPS lock"

[Bill Unruh]

It is almost inconceivable that either the gps or the ntp servers could drift
that far unless there were a complete cutoff. Are your sure that the ntp
sources are not really one single source (Ie all your sources are reliant on a
single source which is drifting away?-- eg they are all sources which are run
by a single company?)
It is also possible that the gps receiver or the antennas are bad, and the gps
receiver is simply free wheeling? Although I would not expect that to give
seconds of offset.

I have no idea what "its lock source goes out of lock" means for the PPS
source.


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 __|_theory.physics.ubc.ca/

On Wed, 18 Jan 2023, Rob Janssen wrote:


[CAUTION: Non-UBC Email]

Miroslav,

No the PPS for sure did not lose lock.  These are either professional GPSDO
sources or we have that extra lock source, and it happens in both cases.
What SURE could happen is that those NTP sources collectively drift to
some offset relative to the PPS due to asymmetric network delay, but
in that case the PPS still is the correct reference.

How it should work: on powerup or upon total loss of lock, it should first
lock in on the NTP sources to get the system clock accurate to within
a few hundred milliseconds, so that the PPS is unambiguous.  Then, it
should lock to the PPS and remain locked unless its "lock" source goes
out of lock, in which case the NTP sources can be used as a backup.

When a PPS source is marked as "trust" but its lock source is not locked,
is it still trusted or will other sources then take over (they should)?


No idea what this sentence means. The source for PPS is the array of
sattelites, which are NOT going to go out of lock unless something very very
bad has happened to the world, in which case chrony is not going to be your
biggest worry.



All NTP sources are systems similar to this (locked to PPS + NTP sources),
it is a network of co-channel transmitters that require precise timing
and they use each other for the startup reference.


Ah, they are all one. Not good. Havint a thousand sources who all get their
time from each other does no good, they are just one, and is bad because ntp
or chrony will thing they are independent and given them far more weight. 
Get other ntp sources-- public ones from the net in there. 


Rob

On 1/18/23 14:41, Miroslav Lichvar wrote:

On Wed, Jan 18, 2023 at 02:14:26PM +0100, Rob Janssen wrote:

refclock    PPS /dev/pps0 refid PPS prefer

and a couple (3-4) external NTP servers as absolute time reference.
What can be the cause of this?  The jitter value displayed in chronyc sources
remains within 5-20us all the time.  But the offset to PPS can go as high as 2ms
during this.  It may be that the combined offsets of the NTP servers as seen by
chrony are closer to another than the PPS source is, but still I don't want 
them to
get selected as long as the PPS can be locked and tracked.

chronyd doesn't cluster sources by their offset. If the PPS source is
marked as x, it doesn't agree with the NTP soures. Are those NTP
sources close in term of root distance? You could use the trust option
to force the selection of the PPS source if you are sure it's correct
and those NTP servers are wrong, but I think it's more likely your PPS
refclock is drifting for some reason, e.g. lost GPS signal. You could
specify a delay of few milliseconds with delay option to ensure an
overlap with the NTP soures.




--
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] RE: Chrony is making NTP Server offline on the system boot

[Bill Unruh]

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 __|_theory.phyesics.ubc.ca/

On Sun, 8 Jan 2023, Iqbal Singh Aulakh -X (iaulakh - HCL AMERICA INC at Cisco) 
wrote:




In normal working sites chrony keeps retrying to connecth to the source and 
doesn't mark the source offline. In fact I can see in the logs after the NTP 
source is marked offline chrony still trys to connect to the source and 
eventually the source responds:



I do not understand. It seems that you are running both ntpd and chrony at the
same time. That makes no sense. Both would be fighting each other. and trying
to drag the clock around to "fix" the time. I may have misread the logs you
postedbut you do not want to run both. ONe or the other. They try to
accomplish the same thing but in very different and incompatible ways.

You could also try tunning ping to some outside machine to see how long it
takes the network to be established.

--
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] ipV4 and ipV6

[Bill Unruh]

Having servers with local is not a good idea at all. Local means that the
servers simply accept their own time as accurate time, and thus do not in any
sense whatsover hand out UTC time to anything that queries them They will
gladly hand out Jan 28 1976 as the time, if that happens to be what their
local clock is set to.

The local directive on a server may be useful if you do not give a damn what 
the time
is that they deliver but you want all your clocks to give the same inaccurate
time. Ie, consistancy is far more important than accuracy.
However if you use two clocks both with local time, or one with local and one
with UTC, your clients will be totally confused, and you will neither get
consistancy or accuracy.
(each client will decide on its own which of the servers to follow).

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 Mon, 28 Nov 2022, chengyechun wrote:




-邮件原件-
发件人: Miroslav Lichvar [mailto:mlich...@redhat.com]
发送时间: 2022年11月28日 16:47
收件人: chrony-users@chrony.tuxfamily.org
主题: Re: [chrony-users] ipV4 and ipV6

On Sat, Nov 26, 2022 at 06:29:55AM +, chengyechun wrote:

Hi all
When the chrony works in both IPv4 and IPv6 modes, for example, one client is 
configured with two servers, one server is iPv4 and the other is ipv6, and the 
NTS function is configured. I found that they were able to communicate, but the 
time source state was displayed as x, which was a bit odd since they didn't 
have a big time difference:
[cid:image001.png@01D901A3.8C0B2D20]


The output shows that the sources are off by ~1.1 seconds from each other, but 
the estimate of accuracy is only in hundreds of microseconds. Their intervals 
don't overlap, so they are marked as falsetickers.
The time difference between the two machines is 1.1s. One machine is fast and 
the other machine is slow. There is no overlap between the two machines. As a 
result, the synchronization is faulty. If cross-connections exist, the system 
displays whether the synchronization is successful or whether the difference 
needs to be kept within the precision range.
It looks like two servers configured with the local reference mode.
That cannot work.
Yes, the two hosts are configured with local stratum.
--
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.


N�Р骒r��y���W!��蚝谦卜??r��+n碰???\ó
"???Р骒r��z)��???n7��Z+��izf???�k??觎???�z�\��'售�}??+???��ウ)��???n7��:韫�^f???X???f???贶��'售�}??+

Re: [chrony-users] Issue with RTC and PPS

[Bill Unruh]

Note also that rtc clock can only be read to the latest second. If all you
care about is time to the nearest second, that is fine, but if you want better
accuracy, it is not 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 Mon, 14 Nov 2022, Bill Unruh wrote:


[CAUTION: Non-UBC Email]

Well, it depends. On most systems I have looked at RTC is worse than the
system clock at keeping time. Yours might be different. If it is worse then
just leaving the system to go ahead on its own time would be the better thing
to do. RTC is then reserved for shutdown and restart. I would certainly not
have RTC as a clock time. rtcsync is a terrible procedure at any time. It 
keeps the rtc at the system

time while the system time is running, but if the system time stops for some
reason rtc will go wandering off on its merry way and as I said, will
generally be worse than the system time left alone. Otherwise chrony will try
to measure the drift rate of the rtc and correct its reading of the rtc 
taking

the rtc drift into account. That is not necessarily great since if the
computer is switched off it is colder than if it is running, and the usual 
rtc
is quite temperature seneistive. Ie, its rate is different cold than warm, 
and
the drift rate calculated when warm is not the drift rate when cold ( but 
when

of course you cannot calibrate it since the computer is not running.

Of course if you have purchased a temperature controlled rtc for the RPI, 
then

it may well be better than computer clock, and your procedure might work.

Remember even if the gps is no longer supplying the signal, chrony has spent 
a

lot of time figuring out what the drift rate is of the clock and can keep
pretty good time.

( and why would your gps signal go down for a significant time? Are you using
your rpi underground somewhere?


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 Mon, 14 Nov 2022, Gabriele Coppi wrote:

[CAUTION: Non-UBC Email]I know that RTC is not ideal and it is not GPS, but 
it is necessary. I know for sure
that it will take some time to lock the GPS signal since the booting of the 
RPi (few minutes). Not only this,
I know that I can lose GPS connection for a long period of time, and that 
is why the rtcsync directive. In my

mind the RTC should be used by chrony during this blackout periods
Also the RTC that I am using is 3.5 ppm, so it should be 1s over few days 


--
Dr. Gabriele CoppiMarie Curie Skłodowska Fellow, 
Department of Physics, Università degli Studi Milano-Bicocca
https://gabrielecoppi.github.io/
Phone Number: +39 0264482356



On Mon, Nov 14, 2022 at 5:27 PM Bill Unruh  wrote:
  I am confused. RTC is NOT GPS. RTC is an onboard (or for the RPI I 
guess a
  supplimentary board) which chrony uses ONLY at startup to set the 
intial
  system clock to approximately the correct time. It tends to drift 
badly --

  1000PPM might be good (That is about a second per hour).

  PPSis pulse per second. It carries zero time information except that 
when the
  pulse is sent, it is exactly (towithin nanoseconds) on the second.It 
needs
  some other clock to tel it what the second is. That other clock is 
either the
  from your GPS receiver or some other clock. Otherwise it assumes that 
the time
  from the system clock is correct for the labeling of which second the 
pulse is
  assocated with. (This may well be fine if the GPS went down for a 
while,
  obviously not so good if the computer switched off. ) Many people use 
gpsd to
  get the seconds label from the GPS sattelite. (that may be what your 
GPS

  source is delivering).

  You will have to find out if your pps is actually delivering pulses. 
Look at
  /sys/devices/virtual/pps/pps0/assert to see if it is increasing its 
pulse
  count (you will also have to determine whether your second pulse 
occurs on

  assert or clear-- probably assert)






  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 Mon, 14 Nov 2022, Gabriele Coppi wrote:

  > [CAUTION: Non-UBC Email]Hello, 
  > I am currently using chrony (v4.0.8) on a RPi4. Due to my 
application, I need to use only GPS,

  PPS a

Re: [chrony-users] Issue with RTC and PPS

[Bill Unruh]

Well, it depends. On most systems I have looked at RTC is worse than the
system clock at keeping time. Yours might be different. If it is worse then
just leaving the system to go ahead on its own time would be the better thing
to do. RTC is then reserved for shutdown and restart. I would certainly not
have RTC as a clock time. 
rtcsync is a terrible procedure at any time. It keeps the rtc at the system

time while the system time is running, but if the system time stops for some
reason rtc will go wandering off on its merry way and as I said, will
generally be worse than the system time left alone. Otherwise chrony will try
to measure the drift rate of the rtc and correct its reading of the rtc taking
the rtc drift into account. That is not necessarily great since if the
computer is switched off it is colder than if it is running, and the usual rtc
is quite temperature seneistive. Ie, its rate is different cold than warm, and
the drift rate calculated when warm is not the drift rate when cold ( but when
of course you cannot calibrate it since the computer is not running.

Of course if you have purchased a temperature controlled rtc for the RPI, then
it may well be better than computer clock, and your procedure might work.

Remember even if the gps is no longer supplying the signal, chrony has spent a
lot of time figuring out what the drift rate is of the clock and can keep
pretty good time.

( and why would your gps signal go down for a significant time? Are you using
your rpi underground somewhere?


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 Mon, 14 Nov 2022, Gabriele Coppi wrote:


[CAUTION: Non-UBC Email]I know that RTC is not ideal and it is not GPS, but it 
is necessary. I know for sure
that it will take some time to lock the GPS signal since the booting of the RPi 
(few minutes). Not only this,
I know that I can lose GPS connection for a long period of time, and that is 
why the rtcsync directive. In my
mind the RTC should be used by chrony during this blackout periods
Also the RTC that I am using is 3.5 ppm, so it should be 1s over few days 

--
Dr. Gabriele CoppiMarie Curie Skłodowska Fellow, 
Department of Physics, Università degli Studi Milano-Bicocca
https://gabrielecoppi.github.io/
Phone Number: +39 0264482356



On Mon, Nov 14, 2022 at 5:27 PM Bill Unruh  wrote:
  I am confused. RTC is NOT GPS. RTC is an onboard (or for the RPI I guess a
  supplimentary board) which chrony uses ONLY at startup to set the intial
  system clock to approximately the correct time. It tends to drift badly --
  1000PPM might be good (That is about a second per hour).

  PPSis pulse per second. It carries zero time information except that when 
the
  pulse is sent, it is exactly (towithin nanoseconds) on the second.It needs
  some other clock to tel it what the second is. That other clock is either 
the
  from your GPS receiver or some other clock. Otherwise it assumes that the 
time
  from the system clock is correct for the labeling of which second the 
pulse is
  assocated with. (This may well be fine if the GPS went down for a while,
  obviously not so good if the computer switched off. ) Many people use 
gpsd to
  get the seconds label from the GPS sattelite. (that may be what your GPS
  source is delivering).

  You will have to find out if your pps is actually delivering pulses. Look 
at
  /sys/devices/virtual/pps/pps0/assert to see if it is increasing its pulse
  count (you will also have to determine whether your second pulse occurs on
  assert or clear-- probably assert)






  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 Mon, 14 Nov 2022, Gabriele Coppi wrote:

  > [CAUTION: Non-UBC Email]Hello, 
  > I am currently using chrony (v4.0.8) on a RPi4. Due to my application, 
I need to use only GPS,
  PPS and RTC
  > for time keeping. The RTC is necessary to preserve the time when GPS 
coverage drops or at boot
  when the GPS
  > lock is not immediate.
  >
  > I have this current chrony.conf directives (other that standard ones) 
  >
  > refclock PPS /dev/pps0 refid PPS trust lock GPS
  > refclock SHM 0 refid GPS precision 1e-1 offset 0.3 delay 0.2 noselect
  > rtcsync
  > rtconutc
  >
  > where  the first two are defining my sources and the second should take 
car

Re: [chrony-users] Issue with RTC and PPS

[Bill Unruh]

I am confused. RTC is NOT GPS. RTC is an onboard (or for the RPI I guess a
supplimentary board) which chrony uses ONLY at startup to set the intial
system clock to approximately the correct time. It tends to drift badly --
1000PPM might be good (That is about a second per hour).

PPSis pulse per second. It carries zero time information except that when the
pulse is sent, it is exactly (towithin nanoseconds) on the second.It needs
some other clock to tel it what the second is. That other clock is either the
from your GPS receiver or some other clock. Otherwise it assumes that the time
from the system clock is correct for the labeling of which second the pulse is
assocated with. (This may well be fine if the GPS went down for a while,
obviously not so good if the computer switched off. ) Many people use gpsd to
get the seconds label from the GPS sattelite. (that may be what your GPS
source is delivering).

You will have to find out if your pps is actually delivering pulses. Look at 
/sys/devices/virtual/pps/pps0/assert to see if it is increasing its pulse

count (you will also have to determine whether your second pulse occurs on
assert or clear-- probably assert)






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 Mon, 14 Nov 2022, Gabriele Coppi wrote:


[CAUTION: Non-UBC Email]Hello, 
I am currently using chrony (v4.0.8) on a RPi4. Due to my application, I need 
to use only GPS, PPS and RTC
for time keeping. The RTC is necessary to preserve the time when GPS coverage 
drops or at boot when the GPS
lock is not immediate.

I have this current chrony.conf directives (other that standard ones) 

refclock PPS /dev/pps0 refid PPS trust lock GPS
refclock SHM 0 refid GPS precision 1e-1 offset 0.3 delay 0.2 noselect
rtcsync
rtconutc

where  the first two are defining my sources and the second should take care of 
the RTC. I would like to use
the rtcfile directive to have chrony to take care of everything but it seems 
that Rasbian Kernel is built
without support for RTC_UEI_ON.

Now I have the following problems, when I shutdown/reboot the RPi:

 1. it seems that chrony never selects the PPS source, and given that GPS is 
marked as noselect, I don't have
any GPS timing
 2. any RTC support is outside chrony, but as said I would like to track it 
with chrony 
I specify that chrony is run as daemon at startup with the -s flag

Any ideas? 

Re: [chrony-users] CEST time is not correct

[Bill Unruh]

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 Thu, 20 Oct 2022, Mahmood Naderan wrote:


[CAUTION: Non-UBC Email] >Run chronyc as root and then give it the command

No difference according to the output below:

$ sudo chronyc sources
210 Number of sources = 22
MS Name/IP address         Stratum Poll Reach LastRx Last sample              
===
^? prod-ntp-5.ntp1.ps5.cano>     0  10     0     -     +0ns[   +0ns] +/-    0ns
^? prod-ntp-4.ntp1.ps5.cano>     0  10     0     -     +0ns[   +0ns] +/-    0ns
^? alphyn.canonical.com          0  10     0     -     +0ns[   +0ns] +/-    0ns
^? pugot.canonical.com           0  10     0     -     +0ns[   +0ns] +/-    0ns
^? prod-ntp-3.ntp1.ps5.cano>     0  10     0     -     +0ns[   +0ns] +/-    0ns
^? prod-ntp-3.ntp4.ps5.cano>     0   6     0     -     +0ns[   +0ns] +/-    0ns
^? prod-ntp-5.ntp4.ps5.cano>     0   6     0     -     +0ns[   +0ns] +/-    0ns
^? prod-ntp-4.ntp1.ps5.cano>     0   6     0     -     +0ns[   +0ns] +/-    0ns
^? ntp2.belbone.be               0  10     0     -     +0ns[   +0ns] +/-    0ns
^? rumst.verbert.be              0  10     0     -     +0ns[   +0ns] +/-    0ns
^? 45.87.78.35                   0  10     0     -     +0ns[   +0ns] +/-    0ns
^? webserver.discosmash.com      0  10     0     -     +0ns[   +0ns] +/-    0ns
^? ntp1.unix-solutions.be        0  10     0     -     +0ns[   +0ns] +/-    0ns
^? host-95-182-219-178.dyna>     0  10     0     -     +0ns[   +0ns] +/-    0ns
^? ntp.ulyssis.student.kule>     0  10     0     -     +0ns[   +0ns] +/-    0ns
^? ntp2.unix-solutions.be        0  10     0     -     +0ns[   +0ns] +/-    0ns
^? ntp.devrandom.be              0  10     0     -     +0ns[   +0ns] +/-    0ns
^? ntp49.kashra-server.com       0  10     0     -     +0ns[   +0ns] +/-    0ns
^? radio-sunshine.org            0  10     0     -     +0ns[   +0ns] +/-    0ns
^? 2a0e:f780:0:100::15           0  10     0     -     +0ns[   +0ns] +/-    0ns
^? time.cloudflare.com           0  10     0     -     +0ns[   +0ns] +/-    0ns
^? 45.87.77.15                   0  10     0     -     +0ns[   +0ns] +/-    0ns

$ sudo chronyc tracking
Reference ID    :  ()
Stratum         : 0
Ref time (UTC)  : Thu Jan 01 00:00:00 1970
System time     : 0.1 seconds slow of NTP time
Last offset     : +0.0 seconds
RMS offset      : 0.0 seconds
Frequency       : 17.605 ppm slow
Residual freq   : +0.000 ppm
Skew            : 0.000 ppm
Root delay      : 1.0 seconds
Root dispersion : 1.0 seconds
Update interval : 0.0 seconds
Leap status     : Not synchronised





>You have network troubles. You do need network working to run chrony.
What do you mean by that? The network is fine.


No it is not. It is not managing to conatact any of your sources.

Make sure you are running logging ( put 
log measurements

into /etc/chrony.conf, and restart chrony

Then look at those measurements.

You may have set up your firewall to block them all.

Re: [chrony-users] CEST time is not correct

[Bill Unruh]

On Wed, 19 Oct 2022, Mahmood Naderan wrote:


[CAUTION: Non-UBC Email]Have no effect, please see below:

$ chronyc sources
210 Number of sources = 22


Why in the world do you have 22 sources? Why are all of them bad (It seems you
do not have your networking working)

MS Name/IP address         Stratum Poll Reach LastRx Last sample
===
^? prod-ntp-5.ntp4.ps5.cano>     0  10     0     -     +0ns[   +0ns] +/-    0ns
^? prod-ntp-4.ntp1.ps5.cano>     0  10     0     -     +0ns[   +0ns] +/-    0ns
^? alphyn.canonical.com          0  10     0     -     +0ns[   +0ns] +/-    0ns
^? pugot.canonical.com           0  10     0     -     +0ns[   +0ns] +/-    0ns
^? prod-ntp-3.ntp4.ps5.cano>     0  10     0     -     +0ns[   +0ns] +/-    0ns
^? prod-ntp-3.ntp1.ps5.cano>     0   6     0     -     +0ns[   +0ns] +/-    0ns
^? prod-ntp-5.ntp4.ps5.cano>     0   6     0     -     +0ns[   +0ns] +/-    0ns
^? prod-ntp-4.ntp4.ps5.cano>     0   6     0     -     +0ns[   +0ns] +/-    0ns
^? ntp2.belbone.be               0  10     0     -     +0ns[   +0ns] +/-    0ns
^? rumst.verbert.be              0  10     0     -     +0ns[   +0ns] +/-    0ns
^? 45.87.78.35                   0  10     0     -     +0ns[   +0ns] +/-    0ns
^? webserver.discosmash.com      0  10     0     -     +0ns[   +0ns] +/-    0ns
^? ntp1.unix-solutions.be        0  10     0     -     +0ns[   +0ns] +/-    0ns
^? host-95-182-219-178.dyna>     0  10     0     -     +0ns[   +0ns] +/-    0ns
^? ntp.ulyssis.student.kule>     0  10     0     -     +0ns[   +0ns] +/-    0ns
^? ntp2.unix-solutions.be        0  10     0     -     +0ns[   +0ns] +/-    0ns
^? ntp.devrandom.be              0  10     0     -     +0ns[   +0ns] +/-    0ns
^? ntp49.kashra-server.com       0  10     0     -     +0ns[   +0ns] +/-    0ns
^? radio-sunshine.org            0  10     0     -     +0ns[   +0ns] +/-    0ns
^? 94-224-67-24.access.tele>     0  10     0     -     +0ns[   +0ns] +/-    0ns
^? time.cloudflare.com           0  10     0     -     +0ns[   +0ns] +/-    0ns
^? 45.87.77.15                   0  10     0     -     +0ns[   +0ns] +/-    0ns


You do not have any sources which are working.  Thus your system has nothing
to sync to.




$ chronyc tracking
Reference ID    :  ()


This means that there is nothing out there to sync to.



Stratum         : 0
Ref time (UTC)  : Thu Jan 01 00:00:00 1970
System time     : 0.1 seconds slow of NTP time
Last offset     : +0.0 seconds
RMS offset      : 0.0 seconds
Frequency       : 17.605 ppm slow
Residual freq   : +0.000 ppm
Skew            : 0.000 ppm
Root delay      : 1.0 seconds
Root dispersion : 1.0 seconds
Update interval : 0.0 seconds
Leap status     : Not synchronised



You have network troubles. You do need network working to run chrony.



$ date
Wed 19 Oct 2022 10:04:11 PM CEST

$ cat  wrote:
  It looks like your computer is not synchronized.
  Try these commands to debug the chrony (and network) configuration:

  chronyc sources
  chronyc tracking

  Rob

  On 10/19/22 19:11, Mahmood Naderan wrote:
  Hi,
I have a problem with the time set on my Ubuntu 20.04 which uses chrony.  As 
you can see below

Re: [chrony-users] Obfusticated data?

[Bill Unruh]

I believe it is for security. The remote system does not need this data on the
intial packets. Also, especially the inital packets time data can be way out.
The ntp time protocol looks at the average time of sending and receiving the
packet, and time set back from the remote system when it receives the packet.
It could take the packet 50ms to travel from your system to the server. (eg I
am just pining a server only 3000km away, and it takes 30ms to go one way).
Furhtermore there are random delays. chrony averages the past N packets ( does
a least squares fit to the delays) for N somwhere between 3 and 50., which is
far more accurate than the delay for any one packet. Thus the chrony clock is
at least a factor of 10 ( and sometimes 100) more accurate than the range of
the offsets of single packets. IF you want to make sure that your system is in
spec, then get yourself a gps timing receiver, and use that to synchrnize your
clocks. That will give you a synchronization to UTC better than 1 microsecond,
5 time more accurate than you need.

The model that your standard seems to be using for time sync looks, from your
description, to be one that that does not understand time standards, and
synchronization.

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, 30 Sep 2022, Mark Notarus wrote:


[CAUTION: Non-UBC Email]

 

As part of our requirements as a trading business, we need to record a lot of 
data about timing, and report
on it if it is out of specification.

 

The CAT standard that governs trading companies specifies that we have to log 
every synchronization event,
the result, and report if we are more than 50ms out of spec.

 

We have been doing that by parsing local logs, which works fine but scales 
terribly.

 

We purchased a grandmaster which among other things uses the self-reported data 
in PTP and NTP packets from
all clients, and logs that in a central place, which makes it the perfect place 
to pull our compliance info
from.

 

While testing, we noticed that Chrony is zeroing out all that data, which means 
we can’t do that. It
definitely seems deliberate.

 

Even if I disable this code, I find that the reported data in the NTP packets 
does not seem to match the data
logged in tracking.log/measurements.log.

 

Could someone help me understand the goal of this data deletion? 

 

 

Ntp_core.c , line 1096, codebase 4.3 .

 

if (my_mode == MODE_CLIENT) {

    /* Don't reveal local time or state of the clock in client packets */

    precision = 32;

    leap_status = our_stratum = our_ref_id = 0;

    our_root_delay = our_root_dispersion = 0.0;

    UTI_ZeroTimespec(_ref_time);

  }

 

 

 

--

Mark Notarus

Sumo Capital Group – Tech Services team

312-548-0718

mn@scgroup.holdings

 

Re: [chrony-users] clients -n missing hosts?

[Bill Unruh]

Why are you dumping all of this here? What is your problem?

If you do not want the hostnames displayed, read the man chronyc file
..
Client commands
   dns option
   The dns command configures how hostnames and IP addresses are 
resolved in chronyc. IP addresses can be
   resolved to hostnames when printing results of sources, sourcestats, 
tracking and clients commands.
   Hostnames are resolved in commands that take an address as argument.

   There are five options:

   dns -n
   Disables resolving IP addresses to hostnames. Raw IP addresses 
will be displayed.
.


Also using IP addresses instead of hostbnames is dangerous, as the server
owner could change the IP on his ntp host, and you could be out of luck.
There is nothing that prevents them from doing so.

On Fri, 6 May 2022, B. Cook wrote:


[CAUTION: Non-UBC Email](I run void btw..) 
chronyc (chrony) version 4.2 (+READLINE +SECHASH +IPV6 -DEBUG)

This is a bare metal machine; not a vm. 
```
 grep -Ev "^#|^$" /etc/chrony.conf
server 209.51.161.238 iburst
server 216.239.35.0 iburst
server 162.159.200.123 iburst
server 129.134.25.123 iburst
logchange 0.5
driftfile /var/lib/chrony/drift
ntsdumpdir /var/lib/chrony/
rtcsync
makestep 1 -1
minsources 2
local stratum 2
bindaddress 172.16.254.241
allow 172.16.0.0/16
allow 10.20.0.0/16
allow 10.120.0.0/16
```

and 

```
 cat /etc/sv/chronyd/run
#!/bin/sh
install -d -m750 -o chrony -g chrony /var/run/chrony
exec chronyd -n -L 1 -f /etc/chrony.conf -u chrony
```

Using dnscrypt-proxy and its cloaking features.. I grab most timeservers 
(*.pool.ntp.org, time.windows.com,
time.apple.com, time-ios.apple.com, etc.. ) and redirect them to our internal 
host, presently 172.16.254.241 

Using wireshark to show we went to the correct server.. and got time.. 

image.png

(great) working.. 

but 

```
 chronyc clients -n | wc -l
3299
```

but where am I?


We sure do not know.




```
# chronyc clients -n  | grep 10.20.28
10.20.28.33                     1      0   -   -   15h       0      0   -     -
10.20.28.10                    93      0  10   -   719       0      0   -     -
```

/flushdns, sync time, /displaydns.. all looks good.. 

image.png

Manually toggled/sync'd time on Windows10.. 

Still not there.. 

again looks like I made it.. 

image.png

and still not there.. 


Where do you want to be?




I just restarted.. 


If you just restarted then chrony time is not going to be very good.




```
 ~# chronyc tracking
                        chronyc sources
                        chronyc sourcestats -v

Reference ID    : 8186197B (time3.facebook.com)
Stratum         : 2
Ref time (UTC)  : Fri May 06 12:29:17 2022
System time     : 0.49408 seconds fast of NTP time
Last offset     : +0.76917 seconds
RMS offset      : 0.76917 seconds
Frequency       : 7.522 ppm fast
Residual freq   : +2.200 ppm
Skew            : 0.125 ppm
Root delay      : 0.005109369 seconds
Root dispersion : 0.000448218 seconds
Update interval : 64.2 seconds
Leap status     : Normal
MS Name/IP address         Stratum Poll Reach LastRx Last sample
===
^? clock.nyc.he.net              1   6   122   109    -75us[+1643ns] +/-   38ms
^- time1.google.com              1   6    37    51  -1514us[-1514us] +/-   14ms
^- time.cloudflare.com           3   6    37    51   +101us[ +101us] +/-   21ms
^* time3.facebook.com            1   6    37    52  -1539ns[  +75us] +/- 2716us
                             .- Number of sample points in measurement set.
                            /    .- Number of residual runs with same sign.
                           |    /    .- Length of measurement set (time).
                           |   |    /      .- Est. clock freq error (ppm).
                           |   |   |      /           .- Est. error in freq.
                           |   |   |     |           /         .- Est. offset.
                           |   |   |     |          |          |   On the -.
                           |   |   |     |          |          |   samples. \
                           |   |   |     |          |          |             |
Name/IP Address            NP  NR  Span  Frequency  Freq Skew  Offset  Std Dev
==
clock.nyc.he.net            3   3    10     +1.845  74795.320  -1304us   452us
time1.google.com            5   4    71    -25.346    172.602  -2915us   355us
time.cloudflare.com         5   4    71     +4.294     56.624   +319us   243us
time3.facebook.com          5   3    70     +2.200     28.450   +113us   162us
```

(confused how I used IPs but it converts to a name..)



Becasue that is what chrony does unless you tell it not to .




I'm open to suggestions, and greatly appreciate any attention anyone feels this 
is worth.. 


Suggestions for what?




I literally have no 

Re: [chrony-users] Using only pre-configured NTP servers or server list from DHCP

[Bill Unruh]

Supply those customers with a conf file with no default servers?


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 Tue, 3 May 2022, Bryan Evenson wrote:


[CAUTION: Non-UBC Email]

I have a default chrony.conf for some headless devices that has a list of 
default NTP servers to use.  These devices will also pull the NTP server list 
from the DHCP server if the DHCP server provides.  Overall this works.  The 
DHCP client appends the additional NTP servers to chrony.conf as expected.  
However, from my understanding chrony will then use any of the NTP servers 
listed in chrony.conf.  I have a customer request that chrony would use only 
the NTP servers provided by the DCHP client.  I'm trying to figure out what my 
options are to make this happen.

Is there any way in chrony.conf to say, "ignore any NTP servers listed above"?  
Or, is there a way to use multiple configuration files.  For example, chrony.conf is the 
base configuration, then tell it to use either chrony_defaultservers.conf or 
chrony_dhcpservers.conf?  Or does someone have any other methods that they have 
implemented that I haven't considered?


Since you have to supply a special chrony.conf file anyway (saying ""ignore
any NTP servers listed above"), just instead put a # at the beginning of those
default entries.



Thanks,
Bryan

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

[chrony-users] What happened to chrony-helper

[Bill Unruh]

What happened to chrony-helper and what has replaced it?


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/

--
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] Is my GPS receiver really less accurate than NTP servers?

[Bill Unruh]

Unfortunaely "symmetric" does not refer to timing as far the ISP is
cconcerned.I usually just means they will provide the same speed upi
as down. So I would certainly believe that there is something in the ISPs
network that is adding abotu 5ms to the route uniformly for all outgoing or
incoming packets. 
If it occurs close enough to you (eg even your inhome router or fibre modem)

then it would be the same for all sources.

Assuming you have the right edge for the pulse, and you are using the pulse (
not the test string) then yes, I would trust the gps as your computer does.


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 Mon, 18 Apr 2022, Dominick C. Pastore wrote:


[CAUTION: Non-UBC Email]

First off, thank you all for the responses. I'm going to reply to 
all three messages in one email so as not to flood everyone's 
inbox.


The graphs are plotting the "Offset" column by server from 
Chrony's measurements.log. I should have mentioned originally, 
this was while Chrony was syncing the local clock from the GPS's 
PPS signal. I figured that was the most useful information to 
plot, but I can plot any of the other logged values as well (like 
delays and dispersions) if that would be useful.


Regarding the PPS pulse edge: I forgot to mention, I did think to 
try using the other edge, but when I configured the PPS source as 
/dev/pps0:clear, Chrony gave an error:


2022-04-17T13:55:20Z Fatal error : CAPTURECLEAR not supported on 
/dev/pps0


I'm not sure how to fix that (if anyone has any ideas, I would be 
grateful), but I assumed the pulse was longer than 2.5ms anyway, 
so I didn't worry about it at the time. In the meantime, I'll try 
measuring the pulse width to see if it happens to be in the same 
ballpark as the offset.


The other possibility everyone mentioned was asymmetric network 
delay. That explanation makes a lot of sense (and the paper Steven 
linked was an interesting read). I can certainly test for that in 
my own equipment. As for what's outside my control: My ISP 
(Verizon FiOS) provides "symmetric" fiber service, though I don't 
know if anything about it is symmetric except the throughput. 
There may be asymmetry elsewhere in the path, but since all 
servers were showing offsets in the same 0ms to 5ms range, that 
seems the least likely.


In any case, it sounds like so long as I can rule out the 
possibility that I'm using the wrong PPS edge, I should trust the 
timing of the GPS's PPS signal more than the time derived from 
other servers (but let me know if anyone disagrees with that 
conclusion or has other thoughts).


I appreciate all the advice.

Thanks,
Nick

On 4/16/22 4:16 PM, Steven Sommars wrote:
Network delay asymmetry can also be introduced by local 
equipment.  The scatterplot below shows the round-trip delay 
between an NTP client and a nearby NTP server.
on my fiber internet service 1) at the local NTP client and 2) 
just above my home router.



If the local client and the remote NTP server both have accurate 
time it can be interesting to compare the request delay (client 
-> server) to the response delay (server -> client).

[Asymmetric delays are common]

This paper 
 may 
be of interest.

image.png

On Sat, Apr 16, 2022 at 2:23 AM Rob Janssen 
mailto:chrony-us...@pe1chl.nl>> wrote:


When you have a systemic offset of external services vs your 
local clocks, it is often caused by asymmetric network delay.
E.g. when using VDSL or Cable, it may well be that your 
uplink and downlink rates are different, and also the error 
correction parameters are different.
In that case all your external servers get offset by some 
value, and it is the GPS time that is right, not those 20 
external references.


I have seen that coming and going on my line, over the 
years.  The telecom operators sometimes decide it is better to 
have reliability than low roundtrip time and enable "long 
interleaving" and similar parameters, often only in one of the 
directions.  But then later they find themselves in a contest 
for low roundtrip times in the gaming world, and they change 
that again.
For quite some time I had an offset of a few ms in my VDSL 
line and even tweaked the config for it.  But at the moment it 
is quite symmetric.


But indeed, also check the pulse width of the PPS signal to 
see if it happens to be the same as your offset.  If so, change 
the PPS edge.


Rob

On 4/16/22 06:24, Dominick C. Pastore wrote:
 >
 > The one thing that does seem a little suspicious is that 
the offsets for all the servers fall pretty uniformly between 
about 0 and +5 milliseconds. That seems a little too 
coincidental, like maybe 5ms is the granularity of the timer 

Re: [chrony-users] Is my GPS receiver really less accurate than NTP servers?

[Bill Unruh]

 have no idea what those graphs mean.

 Yes, I have compared my gps against public time servers and the GPS is a few
 orders of magnitude better.

 One possibility is that you are triggering on the wrong edge of the pulse
 from the GPS.

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, 16 Apr 2022, Dominick C. Pastore wrote:


[CAUTION: Non-UBC Email]

Hello everyone,

I'm sure a bunch of people on this list have seen or tried one of the guides 
out there for setting up a Raspberry Pi as a stratum 1 time server with a GPS 
receiver like one of these:


https://www.adafruit.com/product/2324
https://store.uputronics.com/index.php?route=product/product=60_64_id=81

I'm wondering, has anyone tried comparing their results from one of those 
guides against public time servers? If so, were the results positive (as in, 
at least as accurate and more precise than time from NTP servers)? I ask 
because after setting mine up, I plotted Chrony's reported offset from 
several public time servers ("Offset" column in measurements.log). I got some 
interesting results.


(Before I continue, for those who will wonder about my setup: I'm using a 
Raspberry Pi 3B+ with a Ublox MAX-M8Q GPS receiver and Chrony 4.0. I set the 
boot options to disable tickless mode and the serial console, installed 
cpufrequtils and set the cpu governor to full performance, enabled uart and 
pps and disabled bluetooth and wifi in /boot/config.txt, and uninstalled a 
few unnecessary daemons.)


First, I compared against NTP pool servers. The results here look pretty 
phenomenal: https://i.imgur.com/4At0m1d.png The accuracy from the GPS 
receiver seems to be great. The plot doesn't show the refclock's precision, 
but it was several orders of magnitude better than the servers as well.


Then I measured against public NTP servers run by large tech companies and 
NIST. Notably, apart from time.cloudflare.com, these are all stratum 1 
servers. This is the plot: https://i.imgur.com/eu267CW.png Here, the picture 
doesn't look so rosy. In fact, taking those results at face value, I should 
just abandon the GPS, because it seems I'd get better accuracy by syncing 
with a few of these servers instead. (It makes no noticeable difference 
whether Chrony uses GPSd for the refclock or uses /dev/pps0 directly.)


The one thing that does seem a little suspicious is that the offsets for all 
the servers fall pretty uniformly between about 0 and +5 milliseconds. That 
seems a little too coincidental, like maybe 5ms is the granularity of the


Teh accuracy from a properly setup GPS is of the order of a few hundres of
nanoseconds, a factor of almost 100 from what you are getting. I 
nd no, 5ms is NOT the granularity of the timestamping, unless your system

clock is really bad.

timer used to timestamp the packets or something. But, admittedly, I have no 
other reason to believe the measurements aren't correct, and that sounds like 
an unlikely explanation. I suppose it's possible the PPS from the GPS 
receiver has a constant 2.5ms delay from somewhere, but I'd be a little 
surprised (it's not a timing GPS, but the datasheet still quotes a PPS 
accuracy within 60ns).

Or else your network could be introducing a delay of 2.5ms one way into the
signals from all the network sources.
So are these plots the difference between the offsets of the gps with those of
the verious sites.



So now I'm curious if anyone else with one of these Raspberry Pi setups has 
done any benchmarking like this. If so, what did your results look like? And 
does anyone have any theories about the positive offsets between 0 and 5ms in 
the second plot?


As I mentioned, you may be using the wrong edge of the pps pulse. (2.5ms
sounds like what the pulse width could be).


Thanks,
Nick

--
To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org with 
"unsubscribe" in the subject.
For help email chrony-users-requ...@chrony.tuxfamily.org with "help" in the 
subject.

Trouble?  Email listmas...@chrony.tuxfamily.org.




--
To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org 
with "unsubscribe" in the subject.
For help email chrony-users-requ...@chrony.tuxfamily.org 
with "help" in the subject.

Trouble?  Email listmas...@chrony.tuxfamily.org.

Re: [chrony-users] Re: Restarting the chrony service brakes chrony

[Bill Unruh]

In you original script you told chrony to go offline. That means it does not
query anything. That is consistant with your experience where none of the
servers are queried. If you got rig of the "offline" it would probably work



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 Wed, 6 Apr 2022, Uwe Fechner wrote:


[CAUTION: Non-UBC Email] Dear all,
a colleague of mine found a fix. I changed the start stop script to look like 
this:

#!/bin/sh #
# Start chrony

[ -r /etc/default/chrony ] && . /etc/default/chrony

case "$1" in
  start)
        printf "Starting chrony: "
        chronyd $CHRONY_ARGS && echo "OK" || echo "FAIL"
        printf "Setting chrony online: "
        chronyc online
        ;;
  stop)
        printf "Stopping chrony: "
        killall chronyd && echo "OK" || echo "FAIL"
        ;;
  restart|reload)
        "$0" stop
         sleep 1
        "$0" start
         ;;
  *)
        echo "Usage: $0 {start|stop|restart}"
        exit 1
esac

exit $?

I would still consider this to be a bug. At least the command "chronyc sources" 
should print a hint if no source is available like:
"Did you try: sudo chronyc online"... But OK, you could say its a bug in the 
start stop script provided by buildroot.

___
From: Uwe Fechner 
Sent: Wednesday, April 6, 2022 12:04 PM
To: chrony-users@chrony.tuxfamily.org 
Subject: [chrony-users] Re: Restarting the chrony service brakes chrony  
This email originated from outside of your organization. Please do not click on 
links or open attachments unless you recognize the sender
and know the content is safe.

This is my configuration:

Start script:
[/etc/init.d]$ cat chrony
#!/bin/sh
#
# Start chrony

[ -r /etc/default/chrony ] && . /etc/default/chrony

case "$1" in
  start)
        printf "Starting chrony: "
        chronyd $CHRONY_ARGS && echo "OK" || echo "FAIL"
        ;;
  stop)
        printf "Stopping chrony: "
        killall chronyd && echo "OK" || echo "FAIL"
        ;;
  restart|reload)
        "$0" stop
         sleep 1
        "$0" start
         ;;
  *)
        echo "Usage: $0 {start|stop|restart}"
        exit 1
esac

exit $?

The file /etc/default/chrony:
[/etc/default]$ cat chrony
CHRONY_ARGS="-s -r -f /home/user/etc/chrony.conf"

The file /home/user/etc/chrony.conf:
[~/etc]$ cat chrony.conf
pool pool.ntp.org iburst offline maxdelayratio 2

driftfile /var/lib/chrony/drift
makestep 1.0 3
rtcfile /var/lib/chrony/rtc
rtconutc
rtcautotrim 30

dumpdir /var/run/chrony

Is it allowed to stop chronyd with "killall chronyd" or is there a better way?

The system is running on 32 bit ARM and was created with buildroot.

Any help would be greatly appreciated!

___
From: Uwe Fechner
Sent: Tuesday, April 5, 2022 5:16 PM
To: chrony-users@chrony.tuxfamily.org 
Subject: Restarting the chrony service brakes chrony  
I have a strange problem: When chrony is started after boot all works fine.

chronyc --version
chronyc (chrony) version 4.1 (-READLINE +SECHASH +IPV6 -DEBUG)

After 5 min:
chronyc sources MS Name/IP address         Stratum Poll Reach LastRx Last 
sample              
===
^- excalibur.prolixium.com       2   6   377    13  +5513us[+4097us] +/-   98ms
^+ gowest.hojmark.net            2   6   371    13  -4181us[-5596us] +/-   59ms
^* ntp0.bgwlan.nl                1   6   327    12   -138us[-1553us] +/-   26ms
^? cloud.discloud.biz            2   6     3    13  +2145us[ +729us] +/-   26ms

Now I restart chrony
sudo service chrony restart
and I get after 1 min:
MS Name/IP address         Stratum Poll Reach LastRx Last sample              
===
^? ntp18.kashra-server.com       0   6     0     -     +0ns[   +0ns] +/-    0ns
^? dns02.wsrs.net                0   6     0     -     +0ns[   +0ns] +/-    0ns
^? time.cloudflare.com           0   6     0     -     +0ns[   +0ns] +/-    0ns
^? ntp1.trans-ix.nl              0   6     0     -     +0ns[   +0ns] +/-    0ns

And after 2min
[bmterra@armxl ~]$ chronyc sources MS Name/IP address         Stratum Poll 
Reach LastRx Last sample              
===
^? nts1.time.nl                  0   6     0     -     +0ns[   +0ns] +/-    0ns
^? ntp18.kashra-server.com       0   6     0     -     +0ns[   +0ns] +/-    0ns
^? dns02.wsrs.net                0   6     0     -     +0ns[   +0ns] +/-    0ns
^? 

Re: [chrony-users] chrony (or I210) loses PHC refclock PPS signal?

[Bill Unruh]

Well, probably the easiest way is to get rid of the fluorescent light and
replace it with an incandescent or  LED. The second is to shield the
input/cable (fluorescents tend to be very radio noisy.) That noise should not
affect the Intel card, but it might well affect the unshielded GPS receiver.
Ie, put the receiver into a metal box, and make sure that all the cables
(antenna and connection to the computer) are well shielded.


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, 26 Mar 2022, Fabian wrote:


[CAUTION: Non-UBC Email]

The interface is always up.

I think I might have found the problem, but unsure on how to fix that.
In the room there is a fluorescent lamp, whenever someone switches on the 
light, there is a chance the PPS input on the card will stop.




Am 26.03.2022 um 18:46 schrieb Christopher Hoover:

So when this happens I execute "ifdown eth0 && ifup eth0" and restart
chrony. The refclock is now working again


i'm using i211 with ublox neo 8T and it works well.

is there any chance that something is downing the interface?   The PHC will 
not work if the interface is not up.


It may be worth checking to be sure the interface is still up (ip link or 
ifconfig) next time the problem occurs.


-ch



On Fri, Mar 25, 2022 at 4:37 AM Fabian > wrote:


I have the following setup:

Intel I210 with SDP0 as PPS input from a Ublox M8Q-MAX device.
The Ublox device is set to 1 Hz with 50% pulse width.
chrony 4.2, Debian 11 with Kernel 5.15, i5-8500T

I have configured the refclock:

refclock PHC /dev/ptp0:extpps:nocrossts:pin=0 width 0.5 poll 0
precision
1e-9 pps refid GPS prefer trust

I have attached the whole chrony config down below.

After some time (which seems to be random, 1 - 24 hours) the PHC no
longer produces a PPS interrupt (my guess), leading chrony to no longer
chosing the PHC refclock. LastRx goes up, no longer recovering.
The Ublox module still outputs a 1 Hz pulse as measured by a logic
analyzer (also the LED still blinks).

So when this happens I execute "ifdown eth0 && ifup eth0" and restart
chrony. The refclock is now working again, until the next failure.
Nothing shows up in dmesg regarding this event.

What could be the issue here? I am not sure if this mailing list is the
correct one, as this might also be a kernel issue, or hopefully not a
hardware issue with the Intel NIC.
I have tried some things: different powersupply for the GPS device
aswell as the PC. Different CPU settings (powersafe, performance).
Different Kernels: 5.10, 5.16.

I disconnected the serial output from the GPS. Tried with only PPS and
GND connected, as I thought maybe the serial port was somehow
interfering. Disabled EEE, which probably had no effect anyway as the
switch does not support EEE.

I also tried disconnecting PPS output and reconnecting it again to see
if the pulse would be picked up again, it did.


I'll try to get a chrony debug log when this happens.

Not sure what else I can try. Any hints?

best regards
Fabian

Some additional info:

Time stamping parameters for eth0:
Capabilities:
          hardware-transmit
          software-transmit
          hardware-receive
          software-receive
          software-system-clock
          hardware-raw-clock
PTP Hardware Clock: 0
Hardware Transmit Timestamp Modes:
          off
          on
Hardware Receive Filter Modes:
          none
          all

01:00.0 Ethernet controller: Intel Corporation I210 Gigabit Network
Connection (rev 03)

Settings for eth0:
          Supported ports: [ TP ]
          Supported link modes:   10baseT/Half 10baseT/Full
                                  100baseT/Half 100baseT/Full
                                  1000baseT/Full
          Supported pause frame use: Symmetric
          Supports auto-negotiation: Yes
          Supported FEC modes: Not reported
          Advertised link modes:  10baseT/Half 10baseT/Full
                                  100baseT/Half 100baseT/Full
                                  1000baseT/Full
          Advertised pause frame use: Symmetric
          Advertised auto-negotiation: Yes
          Advertised FEC modes: Not reported
          Speed: 1000Mb/s
          Duplex: Full
          Auto-negotiation: on
          Port: Twisted Pair
          PHYAD: 1
          Transceiver: internal
          MDI-X: off (auto)
          Supports Wake-on: pumbg
          Wake-on: g
          Current message level: 0x0007 (7)
  

Re: [chrony-users] Question about chrony use in a system without RTC battery

[Bill Unruh]

Why not just use the prodedure that both Miroslav and I suggested-- run a cron
job once a minute to touch /var/log/chrony.drift. That should be pretty
reasonable even if the internet went down for a couple of hours before the
power outage. Most of the computer clocks do pretty well freewheeling, so that
time should not be too far out  (less than a second and certainly not fast by
a minute ) for use when chrony comes back up again and the internet comes up
at powerup so that the count is progressive. I would also make sure that that
program which dies if the time ever goes backwards  starts up a few minutes
after chrony comes up again. 
Note also since your program presumably writes out files, you could use the

timestamp on those files instead of chrony.drift as the source for you time at
bootup.

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 Thu, 10 Mar 2022, Kris van Rens wrote:


[CAUTION: Non-UBC Email]

Hi all,

Thanks very much for all the detailed responses! I really appreciate
it -- the online community is just awesome :-)

A couple of answers to questions I got:

On Wed, Mar 9, 2022 at 5:08 PM Daniel Gearty  wrote:


These two considerations may not apply but I will state them anyway:

1) NTP synchronizes UTC.  Local time offsets are handled by the operating
system.  You would need to set the appropriate OS variables so that your
data time is consistent year-round.  Otherwise, the time may SPRING forward
and FALL back from daylight saving time.


Yes, we only use UTC in all our systems. The leap seconds are
considered 'noise' and can be dealt with.



From: Bill Unruh 



Without an rtc it is impossible to have a monotonic time across power
losses, at least for the first little while. If you are willing to wait a
little while
(minutes/seconds) chrony can reset the clock to a reasonable value (within
seconds or milliseconds of UTC, assuming you have access ( internet or local
time source). Eg, use the burst and the makestep directives. Note that
setting the clock to 2050 will produce a step back in time to get to the
right time, so that is of no help.
Make sure that nothing that depends on monotonic time is started before
chrony has been operating and has set the "right " time to within you
tolerances.


At this moment 'automatic' jumps back in time due to a failing RTC are
the most important problem to be tackled. The power/internet outages
we experience are assumed to be temporary (say max. a few days).

The current solution I'm implementing assumes that at one point the
system is able to get an NTP synchronization to start with. From that
point onward a periodic job tests if NTP synchronization is active and
if so: touches the chrony drift file which then can be taken as the
time source of truth. At boot time (before Chrony) a check will be
done if the RTC is (far) behind this time, if so force the time to be
this last set time. From there at some point the actual NTP
synchronization is assumed to be picked up at some point in time
correcting for the outage time (assumed to be a forward jump in time).



---
$ cat /etc/default/chronyd
export OPTIONS='-s -r'


Why not just change the system service file to include those options for
running chronyd?


Good question, but this integrates nicely with Yocto. We now add a
file (/etc/default/chronyd) whereas otherwise we'd have to override
the .service file entirely, or run a sed command to replace the
$OPTIONS value. All are fine solutions I guess.



Why would you break the internet connections. Is that what actually happens
in a powerloss-- the internet goes down for an hour or so first and then the
power loss occurs. And the internet only comes up long after? If not, why is
this your test?


We test many scenarios, as we've seen almost all permutations in the
field. But the scenario of internet going down, then a power outage,
power recovery without internet seems like one of the most worst-case
ones.

Again, thanks for the help, I will report back if I have any more
question or got it working.

Have a nice day, best regards,

Kris

--
To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org
with "unsubscribe" in the subject.
For help email chrony-users-requ...@chrony.tuxfamily.org
with "help" in the subject.
Trouble?  Email listmas...@chrony.tuxfamily.org.




--
To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org 
with "unsubscribe" in the subject.
For help email chrony-users-requ...@chrony.tuxfamily.org 
with "help" in the subject.

Trouble?  Email listmas...@chrony.tuxfamily.org.

Re: [chrony-users] Question about chrony use in a system without RTC battery

[Bill Unruh]

Without an rtc it is impossible to have a monotonic time across power losses,
at least for the first little while. If you are willing to wait a little while
(minutes/seconds) chrony can reset the clock to a reasonable value (within
seconds or milliseconds of UTC, assuming you have access ( internet or local
time source). Eg, use the burst and the makestep directives. Note that setting
the clock to 2050 will produce a step back in time to get to the right time,
so that is of no help. 
Make sure that nothing that depends on monotonic time is started before chrony

has been operating and has set the "right " time to within you tolerances.


On Wed, 9 Mar 2022, Kris van Rens wrote:


[CAUTION: Non-UBC Email]

Hello!

I have a question regarding Chrony use in (Yocto-based) systems that
have no RTC battery, or at least a very short-lived one. The devices
I'm working with regularly have unstable internet connections, and
sometimes lose power all of the sudden (clearing the RTC value).

My main goal is to prevent the system time to jump back. My
application data recording mechanism assumes time to increase
monotonously, and a jump back in time will prevent my application from
writing any data. In a case of a temporary poweroff + RTC value loss,
I'd rather have an erroneous time indication that disregards the
outage time, but at least does not jump back in time. In any normal
situation NTP is always enabled and the internet connection is stable,
but power outages do happen.

I've been testing with Chrony which seems like the right tool for the
job. The NTP synchronization works really well, but I can't seem to
get the power loss situation covered well.

My /etc/chrony.conf looks like this:

---
include /etc/chrony.d/00-custom.conf

pool 0.pool.ntp.org iburst
pool 1.pool.ntp.org iburst
pool 2.pool.ntp.org iburst
pool 3.pool.ntp.org iburst

makestep 1.0 3
driftfile /var/lib/chrony/drift


You have no rtc so why are you giving the rtcfile directive?


rtcfile /var/lib/chrony/rtc
rtcautotrim 1
dumpdir /var/lib/chrony
logdir /var/log/chrony
log tracking
---

The extra configuration file '/etc/chrony.d/00-custom.conf' is empty
for now, but lives in persistent memory, the root filesystem is
readonly. Of course /var is writable too.

I'm using systemd as the startup management system, and have chronyd
set to start up with "-s -r":




---
$ cat /etc/default/chronyd
export OPTIONS='-s -r'


Why not just change the system service file to include those options for
running chronyd?


---

This will pass the $OPTIONS to the system service file. But I don't
really know how to verify this.

My observation with power loss simulations is that the system keeps on
jumping back in time (~a week). What I do is I break the internet
connection such that the NTP synchronization is lost, then pull the
power plug, re-insert the power plug (but leave the internet
connection broken). As far as I could read in the documentation,


Why would you break the internet connections. Is that what actually happens in
a powerloss-- the internet goes down for an hour or so first and then the
power loss occurs. And the internet only comes up long after? If not, why is
this your test?


Chrony should be able to pick up the last modification time from the
driftfile, but this file is not always there. Is there some other way


Well, you could set things up to it is there-- if nothing else set up a cron
job to touch the file every minute.

to force resetting the time at boot to the last modification time
until NTP synchronization is restored?


Delay startup of your application until you are sure that chrony is up and
running. For example, restart it only a minute after the bootup or a minute
after the network has come up again.  That should
be enough time for the makestep to work.




Any help is appreciated, thanks in advance!

Kind regards,

Kris van Rens

--
To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org
with "unsubscribe" in the subject.
For help email chrony-users-requ...@chrony.tuxfamily.org
with "help" in the subject.
Trouble?  Email listmas...@chrony.tuxfamily.org.




--
To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org 
with "unsubscribe" in the subject.
For help email chrony-users-requ...@chrony.tuxfamily.org 
with "help" in the subject.

Trouble?  Email listmas...@chrony.tuxfamily.org.

Re: [chrony-users] a const time offset ahead

[Bill Unruh]

On Wed, 9 Mar 2022, Lin Zhao wrote:


[CAUTION: Non-UBC Email]
  It would help if you gave a complete list for example of the sources 
command

What do you mean of "sources command"? if you mean chrony configuration: 


Run chronyc as root
then type
sources
This will list all of your sources and statistics of them.




  ## Internet server
pool ntp.ubuntu.com iburst maxsources 4


You have access to the network and can use the pool command? Why are you using
nmea then?



driftfile /var/lib/chrony/drift

## Used for NTP time sync for other system (e.g. DVL, Topside, Pi...)
allow 192.168.2.0/24


  ## Used for time sync Jetson from Arduino using gps NMEA string and PPS
makestep 1.0 3
maxupdateskew 100.0
refclock SHM 0 poll 0 refid NMEA precision 1e-1 offset 0.0 trust
refclock PPS /dev/pps1 poll 0 lock NMEA refid PPS precision 1e-6 prefer
initstepslew 30






  How do you hook up the microcontroller, how does it send out the PPS to 
make

  sure it is on the UTC second, How is the NMEA generated, etc.?

1) The computer is connected to the Internet, so it's originally time 
synchronized UTC.
2) The computer and microcontroller have two part connections: 1) USB cable: 
used for data transmission. 2) PPS connection and UART (for pure NMEA)


PPS from what? How does the pps operate on the arduio. I presume it is the
machine that is sending the PPS to the computer. Is it run by gps?


3) Then I will send UTC time at the beginning of one second to microcontroller 
through the USB serial. So the microcontroller time is aligned with
UTC. Obviously, serial transmission will take some time. but it should be very 
small.


No that is not obvious. nmea is very very slow. Thus it is probably off by
many milliseconds.


2) After microcontroller time is aligned with UTC, microcontroller will start 
to count time using hardware timer, and each one second send PPS and
NMEA. NMEA is saved from a real GPS, but I will replace the time information 
that counts inside the microcontroller. 
3) Right now, I can compare computer time and microcontroller time, they are 
the same.
4) Now, I start gpsd and chrony, computer start time synchronized with 
microcontroller. After synchronization, computer time is ahead of the
microcontroller. For example, microcontroller time is 1646779996, computer time 
is 1646779997. 

On Tue, Mar 8, 2022 at 11:46 PM Bill Unruh  wrote:
  PPS has no "seconds" associated with it. It just blips exactly ( to 
withing a
  few ns) on the second. It gets its "seconds" from nmea.
  It would help if you gave a complete list for example of the
  sources
  command. It looks to me like you told it that PPS is off time (ie tried to
  correct the PPS time rather than the NMEA time) It is the NMEA time that 
will
  be off, but .2-.5 seconds usually (late) because the nmea sentence are 
sent
  out after the second, are sent out when the gps is not busy, and take a 
long
  time to get to the computer( it takes a while for the nmea sentence to be
  transmitted). But you have a home grown setup, so the problem could well 
be in
  there.

  How do you hook up the microcontroller, how does it send out the PPS to 
make
  sure it is on the UTC second, How is the NMEA generated, etc.?

  Are you telling chrony that teh PPS is late?



  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 Tue, 8 Mar 2022, Lin Zhao wrote:

  > [CAUTION: Non-UBC Email]Hi,
  >
  > I am using a microcontroller to generate PPS and NMEA string to time 
sync an Nvidia Jetson
  > computer using gpsd and chrony for the GPS-denied environment.  PPS and 
NMEA are verified
  > as good. 
  >
  > When I started time synchronization process, chrony always like:
  > #* PPS                           0   0   1     0    -894ms[  -894ms] 
+/- 1000ns
  >
  > I tried a lot of times, chrony always considers PPS time is ahead 
around 890 ms. But I
  > checked the NMEA time data is right. When the computer is synchronized, 
 system time is
  > ahead of NMEA time. Before the time synchronization, both of them are 
verified the same.
  >
  > After the 1 hour test, time is synchronized, but with this const offset.
  >
  > Could you tell me how to debug this? Thanks for your help.
  >
  > Best regards,
  >
  > -Lin Zhao
  >
  > Research Assistant @ Graduate School of Oceanography 
  > Ph.D. Student @ Department of Ocean Engineering
  > University of Rhode Island
  >
  > Room 2, Horn Lab

Re: [chrony-users] a const time offset ahead

[Bill Unruh]

PPS has no "seconds" associated with it. It just blips exactly ( to withing a
few ns) on the second. It gets its "seconds" from nmea.
It would help if you gave a complete list for example of the 
sources

command. It looks to me like you told it that PPS is off time (ie tried to
correct the PPS time rather than the NMEA time) It is the NMEA time that will
be off, but .2-.5 seconds usually (late) because the nmea sentence are sent
out after the second, are sent out when the gps is not busy, and take a long
time to get to the computer( it takes a while for the nmea sentence to be
transmitted). But you have a home grown setup, so the problem could well be in
there.

How do you hook up the microcontroller, how does it send out the PPS to make
sure it is on the UTC second, How is the NMEA generated, etc.?

Are you telling chrony that teh PPS is late?



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 Tue, 8 Mar 2022, Lin Zhao wrote:


[CAUTION: Non-UBC Email]Hi,

I am using a microcontroller to generate PPS and NMEA string to time sync an 
Nvidia Jetson
computer using gpsd and chrony for the GPS-denied environment.  PPS and NMEA 
are verified
as good. 

When I started time synchronization process, chrony always like:
#* PPS                           0   0   1     0    -894ms[  -894ms] +/- 1000ns

I tried a lot of times, chrony always considers PPS time is ahead around 890 
ms. But I
checked the NMEA time data is right. When the computer is synchronized,  system 
time is
ahead of NMEA time. Before the time synchronization, both of them are verified 
the same.

After the 1 hour test, time is synchronized, but with this const offset.

Could you tell me how to debug this? Thanks for your help.

Best regards,

-Lin Zhao

Research Assistant @ Graduate School of Oceanography 
Ph.D. Student @ Department of Ocean Engineering
University of Rhode Island

Room 2, Horn Lab
215 South Ferry Road
Narragansett RI 02882
Phone: 401-771-4661
E-mail: linz...@uri.edu
Personal: crazymumu0...@gmail.com
Lab: https://soslab.wordpress.com/

Re: [chrony-users] chrony messages not getting to server.

[Bill Unruh]

Can I get chrony to listen on more than one port?


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 Mon, 7 Mar 2022, Miroslav Lichvar wrote:


[CAUTION: Non-UBC Email]

On Fri, Mar 04, 2022 at 01:34:52AM -0800, Bill Unruh wrote:

My home  firewall must be, since other remote systems work fine. How can I
test whether it is open on the server? I assume telnet 123 uses tcp.
How do I send a udp packet to test whether it gets through?


A good way to test that is with mtr in the UDP mode:

mtr -u -P 123 $SERVER_IP

Try it also on a different port and compare the results. It will
probably be shorter for the port 123, indicating a firewall on the
path specifically blocking NTP packets. That's unfortunately quite
common among ISPs as a mitigation against amplification attacks
exploiting the ntpd's mode 6 of the protocol.

If it's your NTP server, you can move it to a different port with the
port directive and specify the port number on clients with the port
option.

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




--
To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org 
with "unsubscribe" in the subject.
For help email chrony-users-requ...@chrony.tuxfamily.org 
with "help" in the subject.

Trouble?  Email listmas...@chrony.tuxfamily.org.

Re: [chrony-users] chrony messages not getting to server.

[Bill Unruh]

My home  firewall must be, since other remote systems work fine. 
How can I test whether it is open on the server? I assume telnet 123 uses tcp.

How do I send a udp packet to test whether it gets through?
The server is behind a university firewall. The claim is that that firewall
lets through udp on port 123. Mind you telnet S 123 gets through so that would
suggest that tcp gets through, if I am right that telnet uses tcp.



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, 4 Mar 2022, Bryan Christianson wrote:


[CAUTION: Non-UBC Email]

NTP is a UDP protocol. Is your firewall open for UDP port 123 ?


On 4/03/2022, at 7:58 PM, Bill Unruh  wrote:

Note that I use other servers (eg a pool server) from my chrony on H, and they 
work fine
so again it does not seem to be a problem with the firewalls/routers between H
and the internet.


NTP is a UDP protocol. Is your firewall open for UDP port 123 at both client 
and server?





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.




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

[chrony-users] chrony messages not getting to server.

[Bill Unruh]

I have one of my ntp servers (It works fine serving a number of other
machines) being called from my home computer. Lets call the server S and the
home machine H. I have S in my chrony.conf file as a server.
I run 
tcpdump -i  port ntp
On both H and S. 
If I do 
telnet S 123

I see the message going out from H, arrive at S and then another packet leaves
S and arrives back at H. So, port 123 is not being blocked by any of the
firewalls between the two.

But, if I run chronyc on H and do a 
burst 3/5 S

I see the packets going out from H, but see nothing arrive at S, or leave from
S back to H.

Does anyone have any hints as to where the packet could be being lost?
when the telnet packet gets through fine.

Note that I use other servers (eg a pool server) from my chrony on H, and they 
work fine
so again it does not seem to be a problem with the firewalls/routers between H
and the internet.


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/

--
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] Synchronize system clock to GPS time

[Bill Unruh]

The gps receivers deliver full UTC time (well GPS time but they are almost
equivalent) Each appropriate sentence from GPS includes the time to the
second. (it is randomly delayed because GPS sentences are delivered with low
priority, and the characters coming over a serial port take about a
a bit less than a msec to be delivered, so an 80  letter sentence takes will
take about 100ms to get to you.)
PPS gives the top of the second to an accuracy which can approach a few
nanoseconds. So GPS can deliver the seconds and pps the fractional part of the
second. GPSD I believe combines them. You could also use just the pps
interrupt and use something else (pool.ntp.com say) to deliver the seconds.


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, 4 Mar 2022, Ryan Govostes (he/him) wrote:


[CAUTION: Non-UBC Email]

Does the PPS ref clock actually provide a time of day or anything, though? I 
thought it merely told us when to tick the second hand forward. Or is GPSD 
combining the two and sending a full timestamp over the socket? In which case, 
do I need the GPS refclock at all?

Or if I need both, how does one calibrate the offset?


On Mar 3, 2022, at 23:36, Bill Unruh  wrote:

Teh two sources GPS and PPS have vastly different uncertainties. so the system
would tend to choose the PPS and ignore the GPS. The GPS will also tend to be
much more than a few standard deviations away from the PPS. So it will not
combine the output of the GPS with the PPS. It is like if you had one server
which gavae you the year and wandered allo f  +- half a year, and another
which gave you nanosecons. You would not want those two averaged to give the
time.

You need to look at the offset of the GPS with respect to the PPS to get a
better idea of how much of an offset you should put in for the GPS. . is
one second, which is almost certainly wrong.



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 __|_ 
https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.theory.physics.ubc.ca%2Fdata=04%7C01%7Crgovostes%40whoi.onmicrosoft.com%7Cd7c24eedb1ac4cd05e8308d9fd98918b%7Cd44c5cc6d18c46cc8abd4fdf5b6e5944%7C0%7C0%7C637819654143563575%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=zqw7eoga2Z%2Fn%2BXQa9JVwPdh265mcK%2FhhnLkrUdcrIm4%3Dreserved=0

On Fri, 4 Mar 2022, Ryan Govostes (he/him) wrote:


[CAUTION: Non-UBC Email] Hi Adrian,
Thanks for the pointers.
asdf.xyz was indeed just a throwaway host instead of my real NTP server. I 
removed that server line but it
did not seem to have an effect.
Then I tried removing the offset 0. from the GPS ref clock — this was 
recommended in some tutorial
somewhere and obviously is not the correct value to use, and when I removed it, 
the system clock updated
right away.
Though now the GPS says it is “not combined” while the PPS is “current synced.” 
Perhaps that is the expected
behavior?
Ryan

 On Mar 3, 2022, at 22:52, Adrian Murphy  wrote:
Hi Ryan,
Can I ask:
 You have ‘prefer’ option added to the 'server asdf.xyz’ line.
 Could that be stopping chronyd from trusting the GPS?
Also, asdf.xyz does resolve to an NTP server for me, but maybe you are hiding 
the real hostname.
On Ubuntu Raspberry Pi4 I use:
 refclock SOCK /run/chrony.pps0.sock refid PPS1 poll 5 prefer
 refclock SHM 0 refid GPS0 precision 1e-20 offset 0.036790 delay 0.0
 server Aeternitas iburst
 …
Also the end of your conf file was garbled. Is that real?
Cheers, Adrian

 On 4 Mar 2022, at 7:07 am, Ryan Govostes (he/him)  
wrote:

 I have a GPS receiver with PPS connected to an embedded Linux system. GPSD 
feeds Chrony
 time updates from the GPS receiver over the Chrony socket.

 The system clock is behind by a few months, and Chrony does not want to 
update the clock to
 the time reported by GPSD.

 I have read the FAQ and a few threads on the same topic but the solutions 
presented
 don’t work for me. I have tried setting maxdistance to an absurdly high 
number, and
 allowing  makestep 1 -1.

 The “chronyc sources� command suggests that Chrony thinks that the GPS 
is in error.
 There is no console message that says that Chrony is attempting to adjust 
the clock.

 Can I force Chrony to accept the time from the GPS?

 Thanks,
 Ryan

 $ chronyc sources
 210 Number of sources = 3
 MS Name/IP address Stratum Poll Reach LastRx Last sample
 
===
 #x GPS   0   4   377

Re: [chrony-users] Synchronize system clock to GPS time

[Bill Unruh]

On Fri, 4 Mar 2022, Adrian Murphy wrote:


[CAUTION: Non-UBC Email]



On 4 Mar 2022, at 2:52 pm, Ryan Govostes (he/him)  wrote:

Hi Adrian,

Thanks for the pointers.

asdf.xyz was indeed just a throwaway host instead of my real NTP server. I 
removed that server line but it did not seem to have an effect.

Then I tried removing the offset 0. from the GPS ref clock — this was 
recommended in some tutorial somewhere and obviously is not the correct value 
to use, and when I removed it, the system clock updated right away.

Though now the GPS says it is “not combined” while the PPS is “current synced.” 
Perhaps that is the expected behavior?


I see this:

Aeon 14:57:~> chronyc sources
MS Name/IP address Stratum Poll Reach LastRx Last sample
===
#* PPS1  0   5   37716   +379ns[ +429ns] +/-  122ns
#x GPS0  0   4   37710   +133us[ +133us] +/-   74us
^- aeternitas.cheese 1  10   377   568-12us[  -12us] +/-  216us


man chronyc
•   x indicates a source which chronyd thinks is a falseticker (i.e. its time 
is inconsistent
   with a majority of other sources, or sources specified with 
the trust option).
- indicates a source which is considered to be selectable for 
synchronisation, but not
   currently selected.



I think x means “not combined”.

I think that is ok. The accuracy of the PPS far exceeds the GPS serial comms. 
+/- 122ns vs +/- 74us. So you wouldn’t want it to be ‘combined'. But the GPS 
informs the PPS driver. But I could be wrong... I was where you are a few 
months ago. I am grateful that the Last Sample value above gets quite small at 
times. And then I start wanting it to be better...

Cheers, Adrian




Ryan


On Mar 3, 2022, at 22:52, Adrian Murphy  wrote:

Hi Ryan,

Can I ask:

 You have ‘prefer’ option added to the 'server asdf.xyz’ line.

 Could that be stopping chronyd from trusting the GPS?

Also, asdf.xyz does resolve to an NTP server for me, but maybe you are hiding 
the real hostname.

On Ubuntu Raspberry Pi4 I use:

 refclock SOCK /run/chrony.pps0.sock refid PPS1 poll 5 prefer
 refclock SHM 0 refid GPS0 precision 1e-20 offset 0.036790 delay 0.0

 server Aeternitas iburst
 …

Also the end of your conf file was garbled. Is that real?

Cheers, Adrian



On 4 Mar 2022, at 7:07 am, Ryan Govostes (he/him)  wrote:

I have a GPS receiver with PPS connected to an embedded Linux system. GPSD 
feeds Chrony time updates from the GPS receiver over the Chrony socket.

The system clock is behind by a few months, and Chrony does not want to update 
the clock to the time reported by GPSD.

I have read the FAQ and a few threads on the same topic but the solutions 
presented don’t work for me. I have tried setting maxdistance to an absurdly 
high number, and allowing  makestep 1 -1.

The “chronyc sources� command suggests that Chrony thinks that the GPS is 
in error. There is no console message that says that Chrony is attempting to 
adjust the clock.

Can I force Chrony to accept the time from the GPS?

Thanks,
Ryan


$ chronyc sources
210 Number of sources = 3
MS Name/IP address Stratum Poll Reach LastRx Last sample
===
#x GPS   0   4   37711   -2002h[ -2002h] +/-  100ms
#x PPS   0   4   37710   -2002h[ -2002h] +/- 2919ns
^? asdf.xyz  0   9 0 - +0ns[   +0ns] +/-0ns

$ chronyc tracking
Reference ID:  ()
Stratum : 0
Ref time (UTC)  : Thu Jan 01 00:00:00 1970
System time : 0.00041 seconds fast of NTP time
Last offset : +0.0 seconds
RMS offset  : 0.0 seconds
Frequency   : 404.716 ppm fast
Residual freq   : +0.000 ppm
Skew: 0.000 ppm
Root delay  : 1.0 seconds
Root dispersion : 1.0 seconds
Update interval : 0.0 seconds
Leap status : Not synchronised

$ cat /etc/chrony/chrony.conf
server asdf.xyz iburst prefer

# This directive specify the file into which chronyd will store the rate
# information
driftfile /var/lib/chrony/chrony.drift

# Log files location
logdir /var/log/chrony

# Stop bad estimates upsetting machine clock
#maxupdateskew 100.0

# This directive enables kernel synchronisation (every 11 minutes) of the
# real-time clock
rtcsync

# Step the system clock instead of slewing it if the adjustment is larger than
# one second, but only in the first three clock updates
makestep 1 -1

#
maxdistance 1

refclock SOCK /run/chrony.ttyCOM2.sock refid GPS precision 1e-1 offset 0.
refclock SOCK /run/chrony.ppsCOM2.sock refid PPS precision 
1e-7N‹§ēæėrļ›y隊W!Ū‰ōšĮŦē·Šđë-rčŸ+nÅöĶŠ\ĻŪ "ķ§ēæėrļ›z)í
ë.n7œīZ+
éizfĒ•ČkĒ|Ūąęė­ęŪzË\†š'ĘÛą}ĐĒ—*+ƒ­†ĨĶ)í
ë.n7œĩ:čđđ^fĒ–XŽķfŽĩę܆š'ĘÛą}ĐĒ—*+



--
To unsubscribe email 

Re: [chrony-users] Synchronize system clock to GPS time

[Bill Unruh]

Teh two sources GPS and PPS have vastly different uncertainties. so the system
would tend to choose the PPS and ignore the GPS. The GPS will also tend to be
much more than a few standard deviations away from the PPS. So it will not
combine the output of the GPS with the PPS. It is like if you had one server
which gavae you the year and wandered allo f  +- half a year, and another
which gave you nanosecons. You would not want those two averaged to give the
time.

You need to look at the offset of the GPS with respect to the PPS to get a
better idea of how much of an offset you should put in for the GPS. . is
one second, which is almost certainly wrong.



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, 4 Mar 2022, Ryan Govostes (he/him) wrote:


[CAUTION: Non-UBC Email] Hi Adrian,
Thanks for the pointers.

asdf.xyz was indeed just a throwaway host instead of my real NTP server. I 
removed that server line but it
did not seem to have an effect.

Then I tried removing the offset 0. from the GPS ref clock — this was 
recommended in some tutorial
somewhere and obviously is not the correct value to use, and when I removed it, 
the system clock updated
right away.

Though now the GPS says it is “not combined” while the PPS is “current synced.” 
Perhaps that is the expected
behavior?

Ryan

  On Mar 3, 2022, at 22:52, Adrian Murphy  wrote:

Hi Ryan,

Can I ask:

 You have ‘prefer’ option added to the 'server asdf.xyz’ line.

 Could that be stopping chronyd from trusting the GPS?

Also, asdf.xyz does resolve to an NTP server for me, but maybe you are hiding 
the real hostname.

On Ubuntu Raspberry Pi4 I use:

 refclock SOCK /run/chrony.pps0.sock refid PPS1 poll 5 prefer
 refclock SHM 0 refid GPS0 precision 1e-20 offset 0.036790 delay 0.0

 server Aeternitas iburst
 …

Also the end of your conf file was garbled. Is that real?

Cheers, Adrian


  On 4 Mar 2022, at 7:07 am, Ryan Govostes (he/him)  
wrote:

  I have a GPS receiver with PPS connected to an embedded Linux system. 
GPSD feeds Chrony
  time updates from the GPS receiver over the Chrony socket.

  The system clock is behind by a few months, and Chrony does not want to 
update the clock to
  the time reported by GPSD.

  I have read the FAQ and a few threads on the same topic but the solutions 
presented
  don’t work for me. I have tried setting maxdistance to an absurdly high 
number, and
  allowing  makestep 1 -1.

  The “chronyc sources� command suggests that Chrony thinks that the 
GPS is in error.
  There is no console message that says that Chrony is attempting to adjust 
the clock.

  Can I force Chrony to accept the time from the GPS?

  Thanks,
  Ryan


  $ chronyc sources
  210 Number of sources = 3
  MS Name/IP address Stratum Poll Reach LastRx Last sample  
 
  
===
  #x GPS   0   4   377    11   -2002h[ -2002h] +/-  
100ms
  #x PPS   0   4   377    10   -2002h[ -2002h] +/- 
2919ns
  ^? asdf.xyz  0   9 0 - +0ns[   +0ns] +/-  
  0ns

  $ chronyc tracking
  Reference ID    :  ()
  Stratum : 0
  Ref time (UTC)  : Thu Jan 01 00:00:00 1970
  System time : 0.00041 seconds fast of NTP time
  Last offset : +0.0 seconds
  RMS offset  : 0.0 seconds
  Frequency   : 404.716 ppm fast
  Residual freq   : +0.000 ppm
  Skew    : 0.000 ppm
  Root delay  : 1.0 seconds
  Root dispersion : 1.0 seconds
  Update interval : 0.0 seconds
  Leap status : Not synchronised

  $ cat /etc/chrony/chrony.conf
  server asdf.xyz iburst prefer

  # This directive specify the file into which chronyd will store the rate
  # information
  driftfile /var/lib/chrony/chrony.drift

  # Log files location
  logdir /var/log/chrony

  # Stop bad estimates upsetting machine clock
  #maxupdateskew 100.0

  # This directive enables kernel synchronisation (every 11 minutes) of the
  # real-time clock
  rtcsync

  # Step the system clock instead of slewing it if the adjustment is larger 
than
  # one second, but only in the first three clock updates
  makestep 1 -1

  #
  maxdistance 1

  refclock SOCK /run/chrony.ttyCOM2.sock refid GPS precision 1e-1 offset 
0.
  refclock SOCK /run/chrony.ppsCOM2.sock refid PPS precision
  1e-7N‹§ēæėrļ›y隊W!Ū‰ōšĮŦē·Šđë-rčŸ+nÅöĶŠ\ĻŪ "ķ§ēæėrļ›z)í
  ë.n7œīZ+
  éizfĒ•ČkĒ|Ūąęė­ęŪzË\†š'ĘÛą}ĐĒ—*+ƒ­†ĨĶ)í
  

Re: [chrony-users] rejecting one of two trusted hosts

[Bill Unruh]

The problem is how do you know which server is serving "good time". The only
notion of time that chrony has is that which is delivered to it by the
servers. There is no other source of time. You order chrony to trust that
those two clocks give good time. But they may disagree, so you do not trust
them. They might be wrong. 
As Miroslav said, chrony uses distance as a criterion for deciding which
server to use. So the fact that time-alt1 is far away is used to downrate it. 
even if all three are trusted.



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 Mon, 14 Feb 2022, Aaron Ball wrote:


[CAUTION: Non-UBC Email]
  If you are willing to accept a majority with time-alt1, why is it not
  trusted?


Well, I'm asking because I'm not clear on how best to express what we want to 
do.
Should we be using "prefer" instead of "trust"? The alternate time servers are 
fine
servers, but far enough away that they won't be setting time precisely enough.

The idea is that, if either tick or tock is serving good time, we want to get 
our time
from them and not consider the alt servers. If they are both up but disagree on 
the
time, historically it's been due to a relatively big difference (e.g., a 1s 
blip from
an upstream PTP source) that put one of them clearly outside the consensus of 
the alt
servers, so chrony's past behavior worked well for us.





--
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] How to measure relative time diff between multiple clients?

[Bill Unruh]

Well, you already have the data since you have the difference between each
machine and your time server, which I assume is a good server. Alternatively
you could bring in say a gps timing receiver, and compare your machines to
that. (with suitable electronics you could attach one gps receiver to multiple
computers if they are close to each other.)
What do you hope to measure (ie, what is the purpose of these measurements).


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 Wed, 9 Feb 2022, Matthew Eshleman wrote:


[CAUTION: Non-UBC Email]Hello,
chrony is now working nicely on the target embedded Linux (ARM) device. 
(Debian, chrony 3.0)

We would like to measure relative time differences between multiple clients 
versus a known decent
NTP server.

Are there any documented best practices, tips, tricks for this effort?

Thank you very much,

Matthew Eshleman

Re: [chrony-users] Debian stretch read only rootfs?

[Bill Unruh]

And what are the permissions for all thos directories?

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, 4 Feb 2022, Matthew Eshleman wrote:


[CAUTION: Non-UBC Email]Thank you to all responding. Sadly still not working.
I added basically all of the indicated folders as tmpfs:

~# df
Filesystem     1K-blocks   Used Available Use% Mounted on
/dev/root         257664 257664         0 100% /
devtmpfs          167400      0    167400   0% /dev
tmpfs             167912      0    167912   0% /dev/shm
tmpfs             167912    980    166932   1% /run
tmpfs               5120      8      5112   1% /run/lock
tmpfs             167912      0    167912   0% /sys/fs/cgroup
tmpfs               1024      0      1024   0% /run/chrony
tmpfs               1024      0      1024   0% /var/db/chrony
tmpfs               1024      4      1020   1% /var/lib/dhcp
tmpfs               2048     20      2028   1% /run_etc_tmpfs
tmpfs             167912      0    167912   0% /tmp
tmpfs               1024      0      1024   0% /var/volatile/lib/chrony
tmpfs               1024      0      1024   0% /var/lib/chrony
tmpfs               1024      0      1024   0% /var/spool
tmpfs               1024     12      1012   2% /var/log
overlay             2048     20      2028   1% /etc
/dev/mmcblk0p5    122835   2669    113613   3% /media/settings

But the end results are the same. Same failure. I've also confirmed that 
systemctl restart fails too, same
message as before.

Additionally, my rev of debian apparently does not show the ReadWritePaths 
attribute. Perhaps we are just
too old at this point?

I also manually ran chronyd, which seemed to run/start. The logs/journal does 
show:

Feb 04 17:33:51 M chronyd[1888]: chronyd version 3.0 starting (+CMDMON +NTP 
+REFCLOCK +RTC +PRIVDROP
+SCFILTER +SECHASH +SIGND +ASYNCDNS +IPV6 -DEBUG)
Feb 04 17:33:51 M chronyd[1888]: Wrong permissions on /run/chrony
Feb 04 17:33:51 M chronyd[1888]: Disabled command socket 
/run/chrony/chronyd.sock

Any further thoughts? 

Best regards,

Matthew



On Fri, Feb 4, 2022 at 10:39 AM Jan Mikkelsen  wrote:
  Hello,
For what it’s worth, I am running chrony on a FreeBSD system with a read-only 
root filesystem
(including read-only /etc) just fine. The places chrony writes on this system 
are /var/run/chrony
and /var/db/chrony.

Regards,

Jan M.


  On 4 Feb 2022, at 17:06, Matthew Eshleman 
 wrote:

Hello all,
I've been experimenting with chrony for an embedded linux system and we have 
decided to move
forward, adding NTP as a feature to this device, using chrony. Previously this 
device only
supported human manual time entry. All experiments to-date have been on a 
development unit
with a fairly normal read/write debian rootfs.

This device is currently using debian stretch, and we use a multistrap approach 
to generate
our rootfs, which is then packaged into a read only rootfs using squashfs for 
our production
configuration.

In my attempts so far, chrony fails to start. We have a ramfs overlay for /etc/ 
and I added
one for /var/lib/chrony as well. The logs/journal did not point me to the exact 
folder/file
that is blocking chrony from starting with a read only root filesystem, and I 
didn't find
specific hints via google (except for some redhat patch, that I do not believe 
applies
here...)

Additionally, I configured chrony to use a drift file that is on a separate 
read/write
partition.

What additional files/folders does chrony need to be read/write?

Logs and such are below:

Feb 04 15:19:34 M systemd[1]: Started Raise network interfaces.
Feb 04 15:19:34 M systemd[1]: Reached target Network.
Feb 04 15:19:34 M systemd[1]: chrony.service: Failed to run 'start' task: 
Read-only file
system
Feb 04 15:19:34 M systemd[1]: Failed to start chrony, an NTP client/server.
Feb 04 15:19:35 M systemd[1]: chrony.service: Unit entered failed state.
Feb 04 15:19:35 M systemd[1]: chrony.service: Failed with result 'resources'.

systemctl status chrony
● chrony.service - chrony, an NTP client/server
   Loaded: loaded (/lib/systemd/system/chrony.service; enabled; vendor preset: e
   Active: failed (Result: resources)
     Docs: man:chronyd(8)
           man:chronyc(1)
           man:chrony.conf(5)

~# df
Filesystem     1K-blocks   Used Available Use% Mounted on
/dev/root         257664 257664         0 100% /
devtmpfs          167400      0    167400   0% /dev
tmpfs             167912      0    167912   0% /dev/shm
tmpfs             167912    960    166952   1% /run
tmpfs               5120      8      5112   1% /run/lock
tmpfs             167912      0    167912   0% /sys/fs/cgroup
tmpfs               1024      0      1024   0% /var/lib/chrony
tmpfs               2048     16      2032   1% /run_etc_tmpfs
tmpfs             167912      0    

Re: [chrony-users] PPS-only PHC refclock

[Bill Unruh]

It would certainly improve the time differences, but would presumably not
change the accuracy of the absolute time. That would be the accuracy of your
(inital) ntp absolute time. So it would depend on what it was that you wanted
the accuracy for.

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 Tue, 1 Feb 2022, Joe Williams wrote:


[CAUTION: Non-UBC Email]Hello list,

I have a NIC that has an OCXO onboard accessible via /dev/ptp2. If I set up 
chrony to use it as a PPS
refclock and have an external NTP server for wall clock time would that work 
and improve accuracy of my
system clock? Would I need to discipline the PHC from system time, presumably 
using phc2sys?

Example config:

server time.facebook.com
refclock PHC /dev/ptp2 pps

Thanks!
-Joe





--
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] chronyd C protocol licensing

[Bill Unruh]

See below.



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 Mon, 3 Jan 2022, Brad Hards wrote:


[CAUTION: Non-UBC Email]

On Monday, 3 January 2022 5:41:31 PM AEDT Bill Unruh wrote:

Well, if you want to be sure, do like Phoenix did with the IBM bios for the
PC. You get one person/team to write out the specification from the source
code for exactly what the data strucures, and queries are. Then you get
another person team which has never seen the code, only the apecification,
and inpliments the program from that, being very careful to document what
was done to ensure that they never saw the source code.

Yes.  That is one option.

You cannot do that yourself, unless you can convince a court that you
sffered a bought of total amnesia between wrting the specification and
writing the code. Otherwise  believe the presumption would be that what you
write would be a derived work.

I don't think it is that clear, but I accept that as a defensible position.


Alternatively, you can get a special licence from the copyright holder to do
what you want. Exactly who the copyright holder would be for chrony is
unclear as a number of people have worked on it and contributed to it.

I don't know how to interpret this statement. Is it "friendly advice from
another user", or are you speaking on behalf of the project?


I am not speaking for the project.




Thirdly you could do as you like and hope  none of the copyright  holders
sue you.

This is an option, but not one I am comfortable with. I had hoped it was
obvious that I was acknowledging the license. If I did not want to respect
licenses, I wouldn't have asked the question.


It is unclear to me which provision of GPL2 you want to violate. Do you want
to release it as prprietary code, and sue anyone who copies it? Do you want
to allow others to do that?

I find this a bit offensive. I do not want to violate the license. I am trying
to make open source software (as noted in my original email), and I'd like to
make it as widely useful as possible. As a Java library, that implies Apache
licensing.

Either my code is a derived work of chrony and it has to be GPL v2 (because
Clause 2), or it isn't, and I can provide it under my choice of license. I'd
like the maintainers' advice.


Whether or not your code is a derived work is a legal question, since the 
concept of "derived work" is a legal one. It is "defined" in the copyright 
law, and in a variety of judgements of the courts in various cases. The 
maintainer cannot define it or state whether or not your actions bring your 
work under the definition. Only the courts can do so. Your best tack would 
seem to me to be either to release it under GPL2, or to get a separate licence
for your program allowing you to release it as you wish. Or to get legal 
advice as to whether or not what you are writing is "derivative" under

copyright law.
Note that, as I understand it, even if the maintainer states that some piece
of code is his, as part of a derived work, it would still fall under the
copyright of the whole work. The same problem would be there in finding
someone to write you a separate licence-- who would have the authority to do
so for all the people who hold copyright in all the bits and pieces (eg, at
least Curnoe and Lichtvar).

My intention was not to be offensive. Copyright law as I understand it, is a
mess, and multi million dollar lawsuits have been fought over things like what
does "derivative work" mean, and the application of those terms to software.
So to really be "safe", just going with the most restrictive licence would be
the best opition. Otherwise, you will have to judge what the probability is
the someone will try to come after you.




Note that I am  not a lawyer, and this is not legal advice.

OK. Thanks.

Brad





--
To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org
with "unsubscribe" in the subject.
For help email chrony-users-requ...@chrony.tuxfamily.org
with "help" in the subject.
Trouble?  Email listmas...@chrony.tuxfamily.org.




--
To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org 
with "unsubscribe" in the subject.
For help email chrony-users-requ...@chrony.tuxfamily.org 
with "help" in the subject.

Trouble?  Email listmas...@chrony.tuxfamily.org.

Re: [chrony-users] chronyd C protocol licensing

[Bill Unruh]

Well, if you want to be sure, do like Phoenix did with the IBM bios for the
PC. You get one person/team to write out the specification from the source
code for exactly what the data strucures, and queries are. Then you get
another person team which has never seen the code, only the apecification, and
inpliments the program from that, being very careful to document what was done
to ensure that they never saw the source code. 
You cannot do that yourself, unless you can convince a court that you sffered

a bought of total amnesia between wrting the specification and writing the
code. Otherwise  believe the presumption would be that what you write would be
a derived work.

Alternatively, you can get a special licence from the copyright holder to do
what you want. Exactly who the copyright holder would be for chrony is
unclear as a number of people have worked on it and contributed to it.

Thirdly you could do as you like and hope  none of the copyright  holders sue
you.

It is unclear to me which provision of GPL2 you want to violate. Do you want
to release it as prprietary code, and sue anyone who copies it? Do you want to
allow others to do that?

Note that I am  not a lawyer, and this is not legal advice.




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 Mon, 3 Jan 2022, Brad Hards wrote:


[CAUTION: Non-UBC Email]

Hi,

I'm working on a Java implementation of the client side of the chronyd command
and monitoring protocol - its up at 
https://github.com/bradh/chrony-java-parent/tree/main/chrony-java

At this stage it doesn't do much - just the tracking request + reply parsing.
I expect to add sources and sourcestats.

As noted at https://chrony.tuxfamily.org/
faq.html#_is_the_chronyc_chronyd_protocol_documented_anywhere the only
documentation for the protocol is the source code. I realise that the source
code to chrony is GPL v2 (only).

While there is no doubt that I used information from the chrony source (in
particular, candm.h and how Float encoding works from util.c), I'm not sure
whether it is a derived work. If possible, I would like to license my
implementation under a more liberal license (e.g. Apache or MIT). Is that OK?

Brad



--
To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org
with "unsubscribe" in the subject.
For help email chrony-users-requ...@chrony.tuxfamily.org
with "help" in the subject.
Trouble?  Email listmas...@chrony.tuxfamily.org.




--
To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org 
with "unsubscribe" in the subject.
For help email chrony-users-requ...@chrony.tuxfamily.org 
with "help" in the subject.

Trouble?  Email listmas...@chrony.tuxfamily.org.

Re: [chrony-users] SV: Allow command do not work as expected

[Bill Unruh]

As Mirislav said, it might be that there were weird non-printing chanracters
in the lines, whichthe chrony interpreter gave up on The one that worked did
not have them and when you copied them over the new lines did not have them.


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 Thu, 30 Sep 2021, Henning Svane wrote:


[CAUTION: Non-UBC Email]

Hi again

 

I have 4 chrony servers and I made the configuration on one of the others and 
here it
worked

So I moved the lines over. And now it work also here, but I cannot see what was 
wrong with the
first attempt.

 

But the problem is now solved.

 

Regards

Henning

 

Fra: Henning Svane 
Sendt: 30. september 2021 13:44
Til: chrony-users@chrony.tuxfamily.org
Emne: [chrony-users] Allow command do not work as expected

 

Hi

 

I have a strange problem.

 

It looks like only the first allow command will be read.

 

I am using version 4.0 on Ubuntu 20.04.3 installed with “sudo apt-get install 
Chrony”

 

From my /etc/chrony/chrony.conf

 

#Allow NTP client access from local network.

#DC Servers

allow 10.40.21.0/28

allow fc00:18f:11ab:4021::/64

allow 10.40.61.0/28

allow fc00:18f:11ab:4061::/64

 

odin@swntp01:~$ sudo chronyc clients

Hostname  NTP   Drop Int IntL Last Cmd   Drop Int  Last

===

10.40.21.12 1  0   -   -   329   0  0   - -

10.40.21.13 1  0   -   -   173   0  0   -     -

10.40.21.11 1  0   -   -    78   0  0   - -

 

If I change the /etc/chrony/chrony.conf to allow All

#Allow NTP client access from local network.

#DC Servers

allow

 

odin@swntp01:~$ sudo chronyc clients

Hostname  NTP   Drop Int IntL Last Cmd   Drop Int  Last

===

10.40.61.11    49  0   5   -    33   0  0   - -

fc00:18f:11ab:4061::11 50  0   6   - 9   0  0   - -

10.40.21.12 1  0   -   -   434   0  0   - -

10.40.21.13 1  0   -   -   278   0  0   - -

10.40.21.11 1  0   -   -   183   0  0   - -

 

 

So what do I do wrong or have misunderstood?

 

Regards

Henning

Re: [chrony-users] Understanding Chrony SOCK time sample "not valid age"

[Bill Unruh]

On Wed, 1 Sep 2021, Chris McKenzie wrote:


[CAUTION: Non-UBC Email]Hi. 
I'm new to the mailing list. I really hope I'm not doing this wrong but I
can't seem to understand how Chrony validates refclock time samples. 


What do you mean by "validates"? You choose the server which you believe has
accurate time. That of course does not mean that it cannot go crazy and start
sending back junk (ie stuff which is no longer related to current time). Which
is whyyou should have at least 3 or maybe more than that, servers, so you can
use a "majority rules" rule. (the time which a majority says is current time
is most likely, the real current time).


I've implemented a C program running on RHEL that needs to forward time
samples from one server to another over a one-way optical link. The time on
the source server is a simple gettimeofday(), it's stored in a message and


Horrible source. Why would you do that. You can get a GPS clock (accurate to
nanoseconds) for about what you pay for a cup of coffee (ok, for coffee for
all of your closest friends). gettimeofday is going to give you time that is
almost certainly seconds, but may be months or millenia out.


sent to the receiving C server program which then pushes a time sample to a
Chrony SOCK. When I test this on my local system it works fine, but between
the servers I receive the following debug logs (I enabled chrony debug
logging):


Perhaps if you told us what you were trying to do, it would help. Or go read
the NTP book by DAvid Mills to understand the theory of ntp.




Sep 01 01:28:31 red-node.local chronyd[14186]: 2021-09-01T01:28:31Z
refclock.c:616:(valid_sample_time) SOCK refclock sample time
1630459715.587552000 not valid age=-4.064528
Sep 01 01:29:31 red-node.local chronyd[14186]: 2021-09-01T01:29:31Z
refclock.c:616:(valid_sample_time) SOCK refclock sample time
1630459775.588427000 not valid age=-4.065328
Sep 01 01:30:31 red-node.local chronyd[14186]: 2021-09-01T01:30:31Z
refclock.c:616:(valid_sample_time) SOCK refclock sample time
1630459835.588663000 not valid age=-4.065453 

My source server is 4 seconds ahead of the target server and I'm a bit
confused because I want to actually have chrony gracefully bring the target
server time (4 seconds) in line with my source server.


That was what ntp was invented for. WHy are you trying to reinvent it?



There's no internet or local NTP server in this situation, so this is the
only way I can feed time into Chrony. I could simply force the local time to
match, but Chrony does all the graceful time adjustment stuff that I would
never be able to get right.

My /etc/chrony.conf:

refclock SOCK /var/run/chrony.sock offset 0.002 delay 1e-9 refid SOCK


I'm using the chrony refclock time sample structure as required:

struct time_sample  {  
    /* Time of the measurement (system time) */  
    struct timeval tv;  
    
    /* Offset between the true time and the system time (in seconds) */
    double offset;
    
    /* Non-zero if the sample is from a PPS signal, i.e. another source  
        is needed to obtain seconds */
    int pulse;
    
    /* 0 - normal, 1 - insert leap second, 2 - delete leap second */
    int leap;
    
    /* Padding, ignored */
    int _pad;
    
    /* Protocol identifier (0x534f434b) */
    int magic;
};


The `not valid age` is not a well documented case, but in the chrony source
that logs that message, there's a basic time sample diff between `now` and
the time sample where anything less than a 0.0 is invalid.

```
static int
valid_sample_time(RCL_Instance instance, struct timespec *sample_time)
{
  struct timespec now;
  double diff;

  LCL_ReadCookedTime(, NULL);
  diff = UTI_DiffTimespecsToDouble(, sample_time);

  if (diff < 0.0 || diff > UTI_Log2ToDouble(instance->poll + 1)) {
    DEBUG_LOG("%s refclock sample time %s not valid age=%.6f",
              UTI_RefidToString(instance->ref_id),
              UTI_TimespecToString(sample_time), diff);
    return 0;
  }

  return 1;
}
```

What this suggests is a time sample containing a time ahead of the receiving
chrony server time will be rejected.

I must be misunderstanding the situation or what time samples are
completely. It makes no sense to me that a time sample sent to a chrony
service that is 4 seconds ahead would reject the time, since its job is to
sync time with/from a source (ahead or behind).

This also could be a SOCK only situation. If it is, please let me know. I'll
have to find another way to update the chrony time. Similarly if you have an
alternative suggestion it would be helpful.

Thank you!

-Chris

Re: [chrony-users] PHC and source selection

[Bill Unruh]

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 Thu, 22 Jul 2021, Ross Ilott wrote:


[CAUTION: Non-UBC Email]Hello,

I have a server running chrony, using a PHC refclock which is PTP-synced via 
ptp4l and also 3 NTP servers in its config. When my
PTP source is not in-sync with GPS time it starts drifting, and you can see the 
effect of this in chrony on my server as follows
(below is when it has drifted ~550us):

210 Number of sources = 4
MS Name/IP address         Stratum Poll Reach LastRx Last sample
===
#* PHC0                          1   2   377     4    +17ns[   +5ns] +/-  523ns
^- asia1    1   6   377    56   +559us[ +560us] +/-   
43ms
^- asia2    1   6   377    56   +565us[ +567us] +/-   
50ms
^- asia3    1   6   377    51   +565us[ +567us] +/-   
50ms

My question is, why does chrony not select a different source in this scenario? 
It has 3 other NTP servers that are perfectly
good, and all seem to agree on the true time. Is it because the estimated error 
of the NTP servers are all ~50ms?


Probably.


These NTP servers are geographically far away (100ms ping), but they themselves 
are synchronised from GPS sources, so their
estimated error shouldn't be half of their network latency, they are much more 
accurate than that. Shouldn't the jitter of their
measurements matter more than their latency?


No. For all the NTP algorithm knows that 50ms is 49ms upsteam and 1 ms
downstream. The only evidence it has is the total roundtrip time.


As far as I can see there is no way to influence the estimated error of an NTP 
time source - is this correct?
Ideally when my local PHC0 source is 500us away from the agreed time from the 
other 3 sources, it would get marked as bad.


But they are all 50ms away from the right time. Why would it want to pick
those?




Thanks!
Ross

chrony tracking:
Reference ID    : 50484330 (PHC0)
Stratum         : 2
Ref time (UTC)  : Thu Jul 22 16:22:59 2021
System time     : 0.00029 seconds fast of NTP time
Last offset     : +0.1 seconds
RMS offset      : 0.00042 seconds
Frequency       : 13.066 ppm fast
Residual freq   : +0.000 ppm
Skew            : 0.005 ppm
Root delay      : 0.00500 seconds
Root dispersion : 0.04934 seconds
Update interval : 4.0 seconds
Leap status     : Normal

The config for chrony is like so:
"
makestep 1 3
rtcsync
hwtimestamp *

driftfile /var/lib/chrony/drift
logdir /var/log/chrony
log rawmeasurements statistics tracking refclocks

leapsectz right/UTC
refclock PHC /dev/ptp0 poll 2 tai delay 500e-9 precision 1e-9 stratum 1

server asia1 minpoll 4 maxpoll 6 iburst
server asia2 minpoll 4 maxpoll 6 iburst
server asia3 minpoll 4 maxpoll 6 iburst
"

and the ptp4l command:
ptp4l -m -f /etc/ptp4l.conf -i nic0

cat /etc/ptp4l.conf:
[global]
clock_servo linreg
delay_mechanism E2E
slaveOnly 1
domainNumber 0

Re: [chrony-users] Forcing chrony to use the clear (falling) edge of negative PPS

[Bill Unruh]

Since it is gpsd that is servicing the interrupt, not chrony, surely you have
to look at gpsd as to how to get it, not chrony, to regard the proper edge of
the pulse.
Or get a non-inverting converter (many serial ports can read ttl fine, despite
what the RS232 standards say, so it is not clear that you need the converter).



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, 3 Jul 2021, ZB wrote:


[CAUTION: Non-UBC Email]Hi Everyone,

I have a Novatel FlexPak G2 that puts out a Negative PPS (because it's going 
through a TTL to RS232
converter, which flips the pulse). The pulse width is 1ms. I have gpsd (v3.22) 
and chrony (v4.1) working
together on my Linux Mint 19.1 machine. 

I have configured chrony to be fed from gpsd as follows in the /etc/chrony.conf 
file:

refclock SHM 0 delay 0.5 refid NMEA 
refclock SOCK /var/run/chrony.ttyS0.sock precision 1e-7 refid PPS

Question:  how can I tell Chrony to use the falling edge (clear edge, which is 
the first leading edge of
the negative PPS) ? 

In the manual it says that you can use the keyword "clear" if you are using the 
PPS reflcock i.e.
reflclock PPS /dev/pps0:clear but since I am using gpsd, I am supposed to use 
the SOCK method, correct
? 

Putting refclock SOCK /var/run/chrony.ttyS0.sock:clear causes chronyd to error 
out. 

Any help appreciated, thanks!

RE: [EXTERNAL] Re: [chrony-users] Allow PPS to take over after NTP is in sync

[Bill Unruh]

On Thu, 10 Jun 2021, Yoed Stavi wrote:


[CAUTION: Non-UBC Email]

Hi Miroslav,

Sorry, I don't know the answer to that and I can't freely access the system to 
check.
I do know that the NTP server was stratum 14 so I imagine that there's plenty 
wrong with the time on it vs. the PPS, in both frequency and offset.


The purpose of the server is to get the seconds right. Ie, for the ntp server,
it is crucial that it be within about 1/2 sec of UTC. After that pps can take
over.  It would probably help us give advice if you gave us specific example
of what ntp does, what pps does and why you say they are in conflict. 
They really cannot be in conflict. ntp server gives the seconds which pps does

not. pps gives the nanoseconds, which the ntp server does not. So where is the
conflict?


Regards,
 Yoed.


-Original Message-
From: Miroslav Lichvar 
Sent: Thursday, 10 June 2021 11:31
To: chrony-users@chrony.tuxfamily.org
Subject: [EXTERNAL] Re: [chrony-users] Allow PPS to take over after NTP is in 
sync

On Thu, Jun 10, 2021 at 08:23:18AM +, Yoed Stavi wrote:

Hi All,

We have an environment where the NTP server and the PPS are in disagreement.


Are they at a constant offset to each other? In that you would specify
the offset for one of the sources to make them agree.

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


--
To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org
with "unsubscribe" in the subject.
For help email chrony-users-requ...@chrony.tuxfamily.org
with "help" in the subject.
Trouble?  Email listmas...@chrony.tuxfamily.org.




--
To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org 
with "unsubscribe" in the subject.
For help email chrony-users-requ...@chrony.tuxfamily.org 
with "help" in the subject.

Trouble?  Email listmas...@chrony.tuxfamily.org.

Re: [chrony-users] System clock off by one hour after suspend

[Bill Unruh]

So, when you look at the clock on the taskbar, it is an hour ahead, but if you
do
date
in a terminal, it gives the correct time?
And what if you do 
date -u

to give UTC? Is that the correct UTC time?


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, 23 Apr 2021, Pete Goodall wrote:


[CAUTION: Non-UBC Email]

Never mind. Embarrassingly I just realised that my system clock is fine. I 
think this might be a problem with GNOME 40.

- Pete


—-

Pete Goodall
Managing Director
Digicratic Consulting
@DigicraticUK
https://digicratic.com

Sent with ProtonMail Secure Email.

‐‐‐ Original Message ‐‐‐

On Friday, April 23rd, 2021 at 17:51, Pete Goodall  wrote:


Hi all,

I've tried to find the answer to this, but it eludes me. Whenever I open

my laptop from suspend the clock is one hour ahead. I can fix it

manually, but I would rather not. I suspect I'm missing some option.

I've seen this before, but it was years ago. Any help would be much

appreciated.

Fedora 34

chrony-4.0-3.fc34.x86_64

Regards,

Pete


---

To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org

with "unsubscribe" in the subject.

For help email chrony-users-requ...@chrony.tuxfamily.org

with "help" in the subject.

Trouble? Email listmas...@chrony.tuxfamily.org.


--
To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org
with "unsubscribe" in the subject.
For help email chrony-users-requ...@chrony.tuxfamily.org
with "help" in the subject.
Trouble?  Email listmas...@chrony.tuxfamily.org.

Re: [chrony-users] chrony startup marks all sources as falseticker

[Bill Unruh]

Although all say it is out by 60 years, the two external are saying that that 
is accurate to (.06 seconds) That
is a lot. The two internal are saying that it is accurate to  1-2ms, 30 to 60 
times
less than the external. Why not try what Miroslav suggests. Or, when you start
up, do a burst from some one source to get the system somewhere near the right
time (not 60 years out). Note that that "days" cannot see the actual time
difference between the two (ie, 60 years and 20ms or 60 years plus 1ms.
say). Perhaps if you showed us the chrony.conf file we might be able to give
better advice.



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 Tue, 6 Apr 2021, Alan Young wrote:


[CAUTION: Non-UBC Email] On 06/04/2021 09:11, Miroslav Lichvar wrote:

On Fri, Apr 02, 2021 at 03:33:26PM +0100, Alan Young wrote:

 MS Name/IP address Stratum Poll Reach LastRx Last sample
 ===
 ^x 199.182.221.110   2   6 0   18h  -18717d[-18717d] +/-   60ms
 ^x 206.75.147.25 2   6 0   18h  -18717d[-18717d] +/-   66ms
 ^x 192.168.63.1144   6 0   18h  -18717d[-18717d] +/- 1115us
 ^x 192.168.63.1214   6 0   18h  -18717d[-18717d] +/- 2394us

   Any idea what is going on here and anything I can do to avoid and/or
   correct the situation?

It looks like its two vs two servers. There is no majority that could
be reached. You can try adding a third public server, so it's three vs
two, or mark one (or both) of two public server with the "trust"
option, so they can override the internal servers.

Thanks for the reply.

Is it really the case that there is no majority? It looks to me like all 4 
servers say the same thing. It is just
that they have all been marked as falsetickers.

It seems like there should be a way of clearing the falseticker flags and 
re-evaluating things, especially when
stuck in startup mode.

Alan.

-- To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org with 
"unsubscribe" in the subject. For help
email chrony-users-requ...@chrony.tuxfamily.org with "help" in the subject. 
Trouble? Email
listmas...@chrony.tuxfamily.org.



--
To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org 
with "unsubscribe" in the subject.
For help email chrony-users-requ...@chrony.tuxfamily.org 
with "help" in the subject.

Trouble?  Email listmas...@chrony.tuxfamily.org.

Re: [chrony-users] need help with large delays reported in ntpdata

[Bill Unruh]

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, 3 Apr 2021, Charbonneau, André wrote:


[CAUTION: Non-UBC Email]

Hi,

I currently have a Linux server getting its time from a 1pps source (atomic 
clock) and 2 stratum
1 servers (for time of day).  My Linux server and stratum 1 servers are 
connected to the same
switch.  The 1pps is from a Rb synchronized to UTC.

 

I’m seeing some weird peer delay and peer dispersion values in the output of 
chronyc ntpdata
command:

...


NTP tests   : 111 111 1101


This says that the source i failing the "delay dev ration" 
The explanation would seem to be


maxdelaydevratio ratio
If a measurement has a ratio of the increase in the round-trip delay from the 
minimum delay amongst the previous measurements to the standard deviation of 
the previous measurements that is greater than the specified ratio, it will be 
rejected. The default is 10.0.

 You could try increasing this max to see if that helps.

 It is not entirely clear to me what this means however. And you sources says
 that the system  has a reach of 377, which means taht the the last 8 contacts
 with the source have been successful.
 Of course this does not say why they have been successfull if they have been
 rejected.



Interleaved : No

Authenticated   : No

TX timestamping : Kernel

RX timestamping : Kernel

Total TX    : 108

Total RX    : 108

Total valid RX  : 108

 

These peer delay and peer dispersion values are quite large (being connected to 
the same switch)
and constant over time (they don’t change).  I was looking at the chrony code 
and this looks like
this could be due because of large estimated error?

 

Here is the output of chronyc sources:

 

$ chronyc sources

210 Number of sources = 3

MS Name/IP address Stratum Poll Reach LastRx Last sample  

===

#* PPS   0   4   377    11   +120ns[ +189ns] +/-   66ns

^- ***.***.52.204    1   5   377   38m  +2040ns[ +347ns] +/-   62us 
(this seems very
large…  I’ve seen this jump to 47ms)

^- ***.***.52.242    1   5   377   39m  +1913ns[ +232ns] +/-   62us

 

The LastRX values for the 2 stratum 1 servers is very large, even though the 
maxpoll is set to 5.

 

So this seems to indicate that there is a NTP test that fails constantly for 
these 2 entries.

 

I’m not sure where to look next to try to figure out what is the root cause of 
this problem.  Any
information about what might explain these constant large delays reported by 
the ntpdata command
and large LastRX values would be much appreciated.

 

Thanks,

  Andre

 

 

CentOS Linux release 7.9.2009 (Core)

 

chronyd (chrony) version 3.4 (+CMDMON +NTP +REFCLOCK +RTC +PRIVDROP +SCFILTER 
+SIGND +ASYNCDNS
+SECHASH +IPV6

+DEBUG)

 

 

 

 

--

Andre Charbonneau

 

Frequency & Time

Metrology Research Centre

National Research Council Canada / Government of Canada

andre.charbonn...@nrc-cnrc.gc.ca / 613-993-3129

 

Fréquence et temps

Centre de recherche en métrologie

Conseil national de recherches Canada / Gouvernement du Canada

andre.charbonn...@nrc-cnrc.gc.ca / 613-993-3129

 

Re: [chrony-users] How to use a "PPS" with freq higher than 1Hz?

[Bill Unruh]

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 Tue, 30 Mar 2021, Vincenzo Miceli wrote:


[CAUTION: Non-UBC Email] Thanks Miroslav,

I was able to get the PPS to start by removing the "lock GPS" and using a 
public NTP. I guess the NMEA
coming from the GPS has too much jitter then? I don't fully understand though 
as the NMEA is always


There is no indication in the pulses that they are associated with 0,
.2, .4,... seconds so all chrony can do is to assume that the gps signal is
assocatied with the "closest" pulse. But the gps signal wanders all over the
place. the GPS receiver only puts out the GPS signal when it is not terribly
busy, and since it comes at a slow rate and is a long string, the lengthof the
string also makes a difference. Associating it with the nearest pulse is fine
at once per sec ( sinc ethe GPS ususlly comes through about 100-200 sec after
the "seconds" mark) for for an accuracy of .2 sec, it is not.


coming once a second and at higher frequencies (I would think) the chrony 
algorithm has to deal with more
samples closer together and can still sample the GPS once a second and compare 
that with the 10 pulses


It does not sample the GPS. The GPS comes in when the receiver wants to send
it and that is always quite late.


per second, maybe with the PPS-GPS separation still working off the 200msec 
limit...  I'm sure there are


10 pulses per 2 sec you said.


good statistical reasons though 


There is a reason why conductors have different wand waves throughout a bar of
music, so musicians know which is the first beat of the bar. There is nothing
like that for PPS. All beats are the same. And GPS is horrible at telling you
which that first beat was.

Anyway, why do you want 5 PPS per second? It does very little to improve the
accuracy of the timekeeping, especially since you are going to use it to no
better accuracy than ms, or I suspect, seconds anyway.




Cheers,

Enzo

_
From: Miroslav Lichvar 
Sent: Tuesday 30 March 2021 13:58
To: chrony-users@chrony.tuxfamily.org 
Subject: Re: [chrony-users] How to use a "PPS" with freq higher than 1Hz?  
On Tue, Mar 30, 2021 at 12:10:33PM +, Vincenzo Miceli wrote:
> refclock PPS /dev/pps0 refid PPS lock GPS precision 1e-9 poll 3 offset 0.0 
rate 5 dpoll -3 prefer
>
> but monitoring with "watch chronyc sources -v" shows no readings from PPS

A higher PPS rate requires a more accurate and stable source for
"locking". For a 5Hz PPS it needs to fit within 40ms. Your screenshot
shows "+/- 100ms". That's too much. You will need to set a smaller
delay for the GPS source.

If that GPS source is not stable enough, you might need to disable the
"lock" option, or use an NTP server, in order to start the PPS refclock.

--
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] Poor synchronization to local NTP server

[Bill Unruh]

On Tue, 16 Mar 2021, Hal Murray wrote:


[CAUTION: Non-UBC Email]


Maybe we should add geographic coordinates to the NTP protocol
so a client can sanity check the round trip times.

Uh, the round trip time is easily measureable. It is one of the things the ntp


Right.  And NTP assumes the routing delays are symmetric.  But it doesn't know
anything about the delays so it has to add 1/2 the round trip time to the
possible error budget.




If you knew the server was on the other side of the country, you could make a
rough estimate of the minimal round trip time and remove that from the error
budget.


Unfortunately the round trip time is largely determined by all of the
switches/routers/... on the way there an back ( which may well be different
routes). It is not simply the straight line distance. While it is true that
the one way trip cannot be less than the distance divided by c, that is not
terriby helpful. So to my uni, 6km away speed of light roundtrip is 40
microseconds, the ping time is 3ms, 100 times as long.

To a computer in Toronto (4000km away) the speed of light round trip is about
26ms, and the ping time is 60ms, about 2.5 times as long. Now one could
perhaps argue that the max error in that one way tip is that excess time
(34ms), which would be better than the 60 ms one might naively assign to it,
but even that reduction by 40% is really irrelevant. None of those estimates
are that accurate anyway.





--
These are my opinions.  I hate spam.




--
To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org
with "unsubscribe" in the subject.
For help email chrony-users-requ...@chrony.tuxfamily.org
with "help" in the subject.
Trouble?  Email listmas...@chrony.tuxfamily.org.




--
To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org 
with "unsubscribe" in the subject.
For help email chrony-users-requ...@chrony.tuxfamily.org 
with "help" in the subject.

Trouble?  Email listmas...@chrony.tuxfamily.org.

Re: [chrony-users] Poor synchronization to local NTP server

[Bill Unruh]

On Tue, 16 Mar 2021, Hal Murray wrote:


[CAUTION: Non-UBC Email]

un...@physics.ubc.ca said:

The length of the hop is not the most important thing. You could have a
stable long hop, or an unstable short hop, and the long hop would deliver
better time.


True, but it could also deliver much worse time if the routing is wildly
asymmetrical.


In which case chrony will probably downgrade it. Of course if the assymetry is
constant, it will not notice.

If you want good close time, set up a gps -- they cost about $50 and you will
get millisecond accuracy to UTC. If you want to use your local server, not
matter how shitty it is, you can list it as the only server, or list it as
preferred.



If you don't know the time, it's hard to figure out if the routing is
symmetric.  I've seen some wildly asymmetric but reasonably stable times from
NIST to Silicon Valley.


Agreed.


Maybe we should add geographic coordinates to the NTP protocol so a client can
sanity check the round trip times.


Uh, the round trip time is easily measureable. It is one of the things the ntp




--
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] Poor synchronization to local NTP server

[Bill Unruh]

On Tue, 16 Mar 2021, Ryan Govostes wrote:


[CAUTION: Non-UBC Email]

I am running ntpd on a local server. That server syncs its clock to 
pool.ntp.org.

Now I want another device, running chrony, to sync its clock to the local 
server, so I configured chrony with `server asdfasdfa iburst`. For comparison I 
also added `server time.nist.gov iburst`.

I’m not sure I’m interpreting the output of chronyc correctly but it seems that it 
is getting a much better fix to the remote NIST server than to the local server 
which is on the same subnet and responds to ping in < 0.5 ms.


That does not matter. What is more important is that asdfasdfa is stratum 4
and probably has a pretty bad root dispersion. The length of the hop is not
the most important thing. You could have a stable long hop, or an unstable
short hop, and the long hop would deliver better time. But in your case,
asdfasdfa has at least 3 hops, each of which could be unstable.



MS Name/IP address Stratum Poll Reach LastRx Last sample
===
^- asdfasdfa 4   6 7 2+39ms[ -669us] +/-  109ms
^* time-d-b.nist.gov 1   6 7 2-16us[  -40ms] +/-   27ms

Name/IP AddressNP  NR  Span  Frequency  Freq Skew  Offset  Std Dev
==
asdfasdfa   8   4   265 -1.772  4.203+39ms   191us
time-d-b.nist.gov   8   6   265 -2.494  9.770-61us   442us

What could I start looking into to diagnose the issue? Is it likely to be 
chrony or the ntp server at fault?


Neither. It is a mispreception that the timing of the hop is the most important
aspect of good time. It is not. 
Note that asdfasdfa has a std deviation of 109ms, while nist has 27ms which is

much better.


Thanks,
Ryan

Re: [chrony-users] Issue with chrony dropping PPS signal

[Bill Unruh]

On some rtcs, it will issue an interrupt when the second rolls over. So it
will be like a PPS signal. Or you can run a poll loop near the second (on your
machine which should be pretty well in time ) to see exactly when the second
rolls over. A bit messy and expensive. And as I said, I do not believe that
the rtc will keep good enough time for your requirements, but you would have
to test that.

Getting GPS to be reliable is certainly a better option.

With GPS you should get microsecond accuracy.



On Mon, 8 Mar 2021, Vincenzo Miceli wrote:


[CAUTION: Non-UBC Email] Thanks Miroslav, Bill, Hal,

I'm dropping the hardware RTC as a backup precision time keeper as the one I 
have (DS3231) doesn't provide sub-second resolution in
its register I would have to use its square wave output etc... which make 
the whole thing impractical. I'll be testing a better
antenna and relocate the GPS receiver outside with better view of the southern 
sky (that's the intended use anyway). 
I will read about the maxclockerror directive and see if that can be used  in 
case of GNSS issues.

Thank you all,

Enzo

__
From: Miroslav Lichvar 
Sent: Monday 8 March 2021 08:30
To: chrony-users@chrony.tuxfamily.org 
Subject: Re: [chrony-users] Issue with chrony dropping PPS signal  
On Fri, Mar 05, 2021 at 03:59:26PM +, Vincenzo Miceli wrote:
> Is there any way for chrony to stop provide time to clients if the PPS signal 
is lost?

No, the server will just keep increasing its root dispersion reported
to its clients, following the NTPv4 specification. The minimum rate
can be configured with the maxclockerror directive.

--
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] Issue with chrony dropping PPS signal

[Bill Unruh]

2PPM = 2 10^-6 which means that in 1 day, it could be out by 200 ms. To test
you want to let your clock be disciplined for at least a day with the GPS, and
then let it freewheel and compare with the rtc.
But I certainly agree that it would be better to have the gps signal. I also
do find it strange that outside, you would be losing the GPS signal for long
times, even at 53 deg north, even with a not great antenna. Is there a defect
with the gps receiver? In fact the density of sattelites there should be at
about the greatest density, since the orbits have an inclination of 55 deg,
and thus they spend more time on the east-west zenith arc at that lattitude.

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 Mar 2021, Vincenzo Miceli wrote:


[CAUTION: Non-UBC Email] Bill, the rtc is temp controlled specc'ed at 2ppms. My 
minimum specification for deviation from UTM is <1msec
at all time. The system as it is now has been capable of <0.1msec excluding 
cold starts and config testing. At the moment it is right
at the window facing south, but it will be in the field in operation next to an 
astronomical telescope. Yes I'm at 53deg N :-)

I should be able to do an experiment were I let freewheel the server and poll 
the rtc to test your hypothesis.

Thanks!

Enzo

Get Outlook for Android


__
From: Bill Unruh 
Sent: Saturday, 6 March 2021, 17:17
To: chrony-users@chrony.tuxfamily.org
Subject: Re: [chrony-users] Issue with chrony dropping PPS signal

But if the chrony instance has been disciplined for a while by a working
chrony, it should be far better, even freewheeling, than the rtc. rtcs are not
designed for accuracy-- just getting the time to approximately the right time
on bootup. Ie, I would trust a freewheeling computer that had been disciplined
more than I would an rtc. (remember that rtc's are also affected by
temperature).

What is the maximum tolerable deviation from UTC for your clock? And how long
does the gps signal drop out? Where is your antenna-- can it see the southern
sky (assuming you are in the nothern Hemisphere).




On Sat, 6 Mar 2021, Vincenzo Miceli wrote:

> [CAUTION: Non-UBC Email]
>
> Because that is the easiest way I see for the client to know that something 
is not right with the time server. This is an isolated
system with no access to other network NTP servers. And if the client is aware 
of a time issue then its software can act accordingly.
I guess another alternative would be for chrony to use the onboard RTC (DS3231) 
as time source, I did try to get chrony to talk to the
RTC but I always received drivers errors on rpi buster...
> I'm pretty sure a proper antenna will do as that is what the other 
"reference" rpi is using while this sketchy one has a small
ceramic patch inside a 1mm PLA dome. That's easy and cheap to test anyway...
> To answer your other question, yes the freewheeling rpi drifts less at 
2.4msec/day while the Win 10 NUC at 8.7msec/day (roughly over
a couple of hours). These figures are likely to get much worse though over 
longer period of time and temp fluctuations... the DS3231
should do be better longer term.
>
> Thanks!
>
> Enzo
>
> [cid:df79ac97-f603-4f8e-9a75-a6f0bbd8b734]
> 
> From: Bill Unruh 
> Sent: Friday 5 March 2021 20:10
> To: chrony-users@chrony.tuxfamily.org 
> Subject: Re: [chrony-users] Issue with chrony dropping PPS signal
>
> Why? The server will keep freewheeling, with both its offset and its rate
> having been adjusted to UTC, so it should keep pretty good time for quite a
> while (even better if you have temperature corrections incorporated into
> chrony). Are all your client clocks that good that they can all keep
> freewheeling time that is as good as or better than your server, since that is
> what will happen if your server stops serving time.
>
> Once your position is known, even one sattelite should give good time. It
> sounds like it is the receiver that is problematic. Is your antenna really
> that borderline?
>
>
> 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/<http://www.theory.physics.ubc.ca/>
>
> On Fri, 5 Mar 2021, Vincenzo Miceli wrote:
>
>> [CAUTION: Non-UBC Email] Hi Miroslav, Hal,
>>
>> it turns out that the GPS loses satellite fix and the PPS s

Re: [chrony-users] Issue with chrony dropping PPS signal

[Bill Unruh]

But if the chrony instance has been disciplined for a while by a working
chrony, it should be far better, even freewheeling, than the rtc. rtcs are not
designed for accuracy-- just getting the time to approximately the right time
on bootup. Ie, I would trust a freewheeling computer that had been disciplined
more than I would an rtc. (remember that rtc's are also affected by
temperature).

What is the maximum tolerable deviation from UTC for your clock? And how long
does the gps signal drop out? Where is your antenna-- can it see the southern
sky (assuming you are in the nothern Hemisphere).




On Sat, 6 Mar 2021, Vincenzo Miceli wrote:


[CAUTION: Non-UBC Email]

Because that is the easiest way I see for the client to know that something is 
not right with the time server. This is an isolated system with no access to 
other network NTP servers. And if the client is aware of a time issue then its 
software can act accordingly. I guess another alternative would be for chrony 
to use the onboard RTC (DS3231) as time source, I did try to get chrony to talk 
to the RTC but I always received drivers errors on rpi buster...
I'm pretty sure a proper antenna will do as that is what the other "reference" 
rpi is using while this sketchy one has a small ceramic patch inside a 1mm PLA dome. 
That's easy and cheap to test anyway...
To answer your other question, yes the freewheeling rpi drifts less at 
2.4msec/day while the Win 10 NUC at 8.7msec/day (roughly over a couple of 
hours). These figures are likely to get much worse though over longer period of 
time and temp fluctuations... the DS3231 should do be better longer term.

Thanks!

Enzo

[cid:df79ac97-f603-4f8e-9a75-a6f0bbd8b734]
____
From: Bill Unruh 
Sent: Friday 5 March 2021 20:10
To: chrony-users@chrony.tuxfamily.org 
Subject: Re: [chrony-users] Issue with chrony dropping PPS signal

Why? The server will keep freewheeling, with both its offset and its rate
having been adjusted to UTC, so it should keep pretty good time for quite a
while (even better if you have temperature corrections incorporated into
chrony). Are all your client clocks that good that they can all keep
freewheeling time that is as good as or better than your server, since that is
what will happen if your server stops serving time.

Once your position is known, even one sattelite should give good time. It
sounds like it is the receiver that is problematic. Is your antenna really
that borderline?


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/<http://www.theory.physics.ubc.ca/>

On Fri, 5 Mar 2021, Vincenzo Miceli wrote:


[CAUTION: Non-UBC Email] Hi Miroslav, Hal,

it turns out that the GPS loses satellite fix and the PPS stops as you have 
predicted. I can fix that by using an active antenna with
much better gain.
Is there any way for chrony to stop provide time to clients if the PPS signal 
is lost?

Thanks again!!

Enzo

__
From: Miroslav Lichvar 
Sent: Thursday 4 March 2021 13:19
To: chrony-users@chrony.tuxfamily.org 
Subject: Re: [chrony-users] Issue with chrony dropping PPS signal
On Thu, Mar 04, 2021 at 01:19:51PM +, Vincenzo Miceli wrote:

Thanks Miroslav,

I want to make sure I understand... you are asking to run something like watch 
-n 1 'cat /sys/class/pps/pps0/assert'   next time I

detect the issue and see if the result is changing to indicate PPS is still 
being issued by the GPS right?

I'll do that then.


Yes, or collect it in a log to not miss it, e.g. every 10 seconds, or
use the script Hal linked.

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







--
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] Issue with chrony dropping PPS signal

[Bill Unruh]

Why? The server will keep freewheeling, with both its offset and its rate
having been adjusted to UTC, so it should keep pretty good time for quite a
while (even better if you have temperature corrections incorporated into
chrony). Are all your client clocks that good that they can all keep
freewheeling time that is as good as or better than your server, since that is
what will happen if your server stops serving time.

Once your position is known, even one sattelite should give good time. It
sounds like it is the receiver that is problematic. Is your antenna really
that borderline?


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, 5 Mar 2021, Vincenzo Miceli wrote:


[CAUTION: Non-UBC Email] Hi Miroslav, Hal,

it turns out that the GPS loses satellite fix and the PPS stops as you have 
predicted. I can fix that by using an active antenna with
much better gain.
Is there any way for chrony to stop provide time to clients if the PPS signal 
is lost?

Thanks again!!

Enzo

__
From: Miroslav Lichvar 
Sent: Thursday 4 March 2021 13:19
To: chrony-users@chrony.tuxfamily.org 
Subject: Re: [chrony-users] Issue with chrony dropping PPS signal  
On Thu, Mar 04, 2021 at 01:19:51PM +, Vincenzo Miceli wrote:
> Thanks Miroslav,
>
> I want to make sure I understand... you are asking to run something like 
watch -n 1 'cat /sys/class/pps/pps0/assert'   next time I
detect the issue and see if the result is changing to indicate PPS is still 
being issued by the GPS right?
> I'll do that then.

Yes, or collect it in a log to not miss it, e.g. every 10 seconds, or
use the script Hal linked.

--
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] Will it EVER synch and start serving?

[Bill Unruh]

Why not try Lichvar's suggestion and post your configuration (chrony.conf) as
this may well be a configuration problem. Or a DNS problem.

(eg, my system cannot resolve any of your sources. ARe those just phony names
to protect something, or are they names you got from some document assuming
they were real?)


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 Mon, 1 Mar 2021, Aaron D. Gifford wrote:


[CAUTION: Non-UBC Email]

On 3/1/21 1:36 AM, Miroslav Lichvar wrote:

On Sat, Feb 27, 2021 at 02:23:04PM -0700, Aaron D. Gifford wrote:
I'm running Chrony version 4.0 on FreeBSD. And I just can't seem to ever 
get

chronyd to sync and start offering time services.


Try the "chronyc selectdata" command. If that doesn't help, please
post your config. It doesn't look like an NTP issue. There has to be
something that blocks the selection.


SELECTDATA OUTPUT:
 .-- State: N - noselect, M - missing samples, d/D - large distance,
/   ~ - jittery, w/W - waits for others, T - not trusted,
|x - falseticker, P - not preferred, U - waits for update,
|S - stale, O - orphan, + - combined, * - best.
|Effective options --.  (N - noselect, P - prefer
|   Configured options -. \  T - trust, R - require)
|   Auth. enabled (Y/N) -.   \ \ Offset interval --.
||| |   |
S Name/IP AddressAuth COpts EOpts Last Score Interval  Leap
===
W timesource-1-example.org  N - -   61   1.0  -253ms  -207ms  N
W timesource-2-example.org  N - -0   1.0  -251ms  -184ms  N
W timesource-3-example.org  N - -  330   1.0  -232ms  -205ms  N
W timesource-4-example.org  N - -  464   1.0  -306ms  -126ms  N
W timesource-5-example.org  N - -  986   1.0  -234ms  -201ms  N
W timesource-6-example.org  N - -  401   1.0  -235ms  -202ms  N
W timesource-7-example.org  N - -  513   1.0  -233ms  -201ms  N
W timesource-8-example.org  N - -  473   1.0  -227ms  -210ms  N
W ip6timesource.example.or> N - -  576   1.0  -227ms  -207ms  N

W = "waits for others" - They're all waiting on what?  How do I find out 
more?


Thanks!

Aaron out.

--
To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org with 
"unsubscribe" in the subject.
For help email chrony-users-requ...@chrony.tuxfamily.org with "help" in the 
subject.

Trouble?  Email listmas...@chrony.tuxfamily.org.




--
To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org 
with "unsubscribe" in the subject.
For help email chrony-users-requ...@chrony.tuxfamily.org 
with "help" in the subject.

Trouble?  Email listmas...@chrony.tuxfamily.org.

RE: [chrony-users] interpolation of offsets in chrony - a robust approach

[Bill Unruh]

I think it might well be interesting. The problem is chrony's adaptive process
for deciding if a linear fit is a reasonable hypothesis, but looking at the
number of consecutive points on one side or the other. It is not at all clear
how one would impliment that in the Thiel-Sen procedure. I suppose one could
divide the points into two bunches and see if the slopes in the two were
consistant to within the estimated errors. But of course estimating the errors
is tough with not many points in the Thiel-Sen procedure. Note that the
procedure would also be expensive in storage-- you have to save n^2 slopes
rather than just n points. And you have to correct n^2 slopes when you change
the drift rate of the clocks instead of just the offsets of n points.




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 Wed, 17 Feb 2021, Charlie Laub wrote:


Well, if there is some interest in seeing how the Thiel-Sen estimator compares to how 
chrony processes the data now, I would be happy to try an do some coding. I think it 
would interesting do to a "real world" comparison, actually.


-Original Message-----
From: Bill Unruh 
Sent: Wednesday, February 17, 2021 1:08 PM
To: chrony-users@chrony.tuxfamily.org
Subject: Re: [chrony-users] interpolation of offsets in chrony - a robust 
approach

iYes, the key difference between chrony and ntpd is that chrony does a linear 
regression on the last n samples to estimate the frequency and the offset now.
It figures out how many n to keep by looking at the number of consecutive 
samples which are above or below the regression line. If there are too many 
that suggests that the curve is not being well fitted by a linear regression, 
and the number of n used is decreased until the consecutive test is passed.
The number is then increased by one at time until the the test begins to be 
failed again. I belive the min samples and max samples tell what the maximum 
number of consecutive good sample are used, and the minimum number that are 
retained. The default at least used to 3 for minsamples (so a linear curve with 
at least some estimate of the errors can be fit) The max used to be 64 but 
these are now configurable if you know what you are doing.

These attributes of chrony allow it to make a much better estimate of the 
current offset and drift than does ntpd

Note that every time the rate of the clock is changed, all of the samples are 
also changed to reflect that change in rate. Or if the clock offset it jumped, 
all the retained samples are changed to reflect that jump. Otherwise the 
fitting would get all messed up.


If the noise is dominated by for example, poisson noise process, your estimator 
might be of advantage (given the cost that you state). but in ntp case it is a 
mixture of poisson and gaussian. In most situations the gaussian probably 
dominates. In some cases it does not, where a different analysis technique 
might be better. But I think you really would have to run simulation 
experiments both withsimulated data where some noise statistics is chosen, and 
with real data to see how much difference it makes. One also has to be worried 
about potential instabilities in the analysis one performs.
One way of handling outliers is to simply throw them away. Eg if a data point 
is 5sigma away from the best fit curve, one could simply eliminate it, and try 
again. This is what is done when the data is accumulated and only the median of 
the passed on to chrony. Typically only the 60 or 70% of the data points that 
lie closest together are used. This is to get rid of what David Mills called 
popcorn noise.

The problem is that there really are no great models for the noise, and 
besides, almost every implimentation is faced with different noise sources.
Also, the more complex one makes the analysis, the higher the probability that 
subtle (or not so subtle) bugs creep in, obviating all of the work.





Willia 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 Wed, 17 Feb 2021, Charlie Laub wrote:



While I was reading the docs I came across these parameters:

maxsamples [samples]

The maxsamples directive sets the default maximum number of
samples that chronyd should keep for each source. This setting can be 
overridden for individual sources in the server and refclock directives. The 
default value is 0, which disables the configurable limit. The useful range is 
4 to 64.

As a special case, setting maxsamples to 1 disables frequency
tracking in order to make the sources immediately selectable with only o

Re: [chrony-users] interpolation of offsets in chrony - a robust approach

[Bill Unruh]

iYes, the key difference between chrony and ntpd is that chrony does a linear
regression on the last n samples to estimate the frequency and the offset now.
It figures out how many n to keep by looking at the number of consecutive
samples which are above or below the regression line. If there are too many
that suggests that the curve is not being well fitted by a linear regression,
and the number of n used is decreased until the consecutive test is passed.
The number is then increased by one at time until the the test begins to be
failed again. I belive the min samples and max samples tell what the maximum
number of consecutive good sample are used, and the minimum number that are
retained. The default at least used to 3 for minsamples (so a linear curve
with at least some estimate of the errors can be fit) The max used to be 64
but these are now configurable if you know what you are doing.

These attributes of chrony allow it to make a much better estimate of the
current offset and drift than does ntpd

Note that every time the rate of the clock is changed, all of the samples are
also changed to reflect that change in rate. Or if the clock offset it jumped,
all the retained samples are changed to reflect that jump. Otherwise the
fitting would get all messed up.


If the noise is dominated by for example, poisson noise process, your
estimator might be of advantage (given the cost that you state). but in ntp
case it is a mixture of poisson and gaussian. In most situations the gaussian
probably dominates. In some cases it does not, where a different analysis
technique might be better. But I think you really would have to run simulation
experiments both withsimulated data where some noise statistics is chosen, and
with real data to see how much difference it makes. One also has to be worried
about potential instabilities in the analysis one performs. 
One way of handling outliers is to simply throw them away. Eg if a data point

is 5sigma away from the best fit curve, one could simply eliminate it, and try
again. This is what is done when the data is accumulated and only the median
of the 
passed on to chrony. Typically only the 60 or 70% of the data points that lie

closest together are used. This is to get rid of what David Mills called
popcorn noise.

The problem is that there really are no great models for the noise, and
besides, almost every implimentation is faced with different noise sources. 
Also, the more complex one makes the analysis, the higher the probability that

subtle (or not so subtle) bugs creep in, obviating all of the work.





Willia 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 Wed, 17 Feb 2021, Charlie Laub wrote:



While I was reading the docs I came across these parameters:

maxsamples [samples]

    The maxsamples directive sets the default maximum number of samples that 
chronyd should keep for each source. This setting can be overridden for 
individual sources in the
server and refclock directives. The default value is 0, which disables the 
configurable limit. The useful range is 4 to 64.

    As a special case, setting maxsamples to 1 disables frequency tracking in 
order to make the sources immediately selectable with only one sample. This can 
be useful when
chronyd is started with the -q or -Q option.

 

minsamples [samples]

    The minsamples directive sets the default minimum number of samples that 
chronyd should keep for each source. This setting can be overridden for 
individual sources in the
server and refclock directives. The default value is 6. The useful range is 4 
to 64.

    Forcing chronyd to keep more samples than it would normally keep reduces 
noise in the estimated frequency and offset, but slows down the response to 
changes in the frequency
and offset of the clock. The offsets in the tracking and sourcestats reports 
(and the tracking.log and statistics.log files) may be smaller than the actual 
offsets.

 

Maybe I am way off here, but the descriptions suggest that these retained 
samples are interpolated using a linear or other form, and then the 
interpolated info is used by
chrony. Is that correct?

 

The offset data is obviously noisy. In addition I have observed on my own 
machines that there can be occasional outliers that are on the order of 10x 
larger than usual. So the
data also has outliers.

 

A linear regression is not the best way to process this kind of data. Instead a 
robust analysis method is best. There is a simple and effective one for 
obtaining the “best fit”
slope of a dataset called a Thiel-Sen estimator. There is a great Wikipedia 
entry for it if you are not familiar with the technique (not sure if links are 
allowed so I did not
include it). In a nutshell, the slope for all pairs of points in the 

RE: [chrony-users] chrony not observing maxpoll - bug?

[Bill Unruh]

Again, use the debugging infomation that chrony produces. In particular make
sure that you have
logdir /var/log/chrony
log measurements statistics tracking
in /etc/chrony.conf on your clients. 
Then after a while look at /var/log/chrony/measurements.log

and see if the client  is getting the packets.

Yes, wireless is not a good way of getting ntp packets. It is notoriously
unreliable in getting packets from one to the other on time. 
Especially if the connection is being hogged by things like video or music

streaming.





On Sun, 7 Feb 2021, Charlie Laub wrote:



I may have figured out what has been going on. The clients are connected via 
WiFi, and I am streaming audio to them as well. It appears that a significant
fraction of the server queries are lost/dropped (or perhaps chrony throws them 
out for one reason or another) under this scheme. I arrived at this conclusion
after performing the following: I set the polling to have a constant 8 second 
interval, and then I had a script produce the output from chronyc sources every 
8
seconds. I looked at the Rx value (time last good response was received), which 
should be 8 seconds or less, depending on when in the cycle I happened to query
it. If the value was over 8 seconds, this must be due to longer intervals 
between replies from the local server. Sure enough, with the audio streaming, 
this
sometimes grew to over 60 seconds. I find that a little strange, because the 
server is on my own LAN and connected by a hardwire to the router. But perhaps
because the channel is in constant use by the audio stream, which is assigned 
high priority by my router via Qos rules, the NTP packets might just not get
through on a regular and “timely” basis.

 

The solution I have put into place was to add a USB WiFi adapter to each client 
(an R-Pi 4). I use the Pi’s built in WiFi for NTP/chrony, and the USB adapter 
for
the audio stream. I used the bindacqaddress directive to restrict chrony to the 
built-in adapter, and the audio stream can be directed to the other using my
streaming audio software. Initial testing shows that very few server queries 
are dropped, so this is likely a good solution to my problem.

 

The only thing that I might be able to tailor and improve is why and when 
chrony drops or invalidates server replies. If anyone has any advice in that 
regard I
would like to know it. Thanks.


Get the data first. See above.



 

-Charlie

 

 

From: Charles Laub 
Sent: Friday, February 5, 2021 2:42 PM
To: chrony-users@chrony.tuxfamily.org
Subject: [chrony-users] chrony not observing maxpoll - bug?

 

Background: I need to keep several machines well synchronized to my local NTP 
reference. This is for audio work, where playback needs to be tightly 
synchronized
between multiple computers. I previously used NTP for many years for this, but 
have recently switched to chrony to take advantage of its time smoothing and
filtering capabilities. I have a local "server" in my basement where the temp 
remains constant. It's a stable reference for other computers in my home. My
machines only poll only this one sever.

 

On various Linux clients, I am experiencing the following issue:

 

Chrony works as expected. Synchronization is achieved to high precision, e.g. 
tens to few hundred microseconds.

I use a fixed polling interval by setting minpoll and maxpoll to e.g. 2

To keep track of what is going on I print out the last offset every 60 seconds 
in an ssh terminal session

I have noticed sometimes that this value gets "stuck". Here is some example 
output:

Last offset : +0.001239868 seconds
Last offset : -0.001022636 seconds
Last offset : +0.000342921 seconds
Last offset : -0.000313532 seconds
Last offset : -0.001234458 seconds
Last offset : -0.001234458 seconds
Last offset : -0.000906603 seconds
Last offset : -0.000906603 seconds
Last offset : -0.36374 seconds
Last offset : -0.000354126 seconds
Last offset : -0.000354126 seconds
Last offset : -0.10771 seconds
Last offset : -0.10771 seconds
Last offset : -0.10771 seconds
Last offset : -0.10771 seconds
Last offset : -0.000411757 seconds
Last offset : -0.000411757 seconds
Last offset : -0.000411757 seconds

 

It dawned on me later that this should not be happening, and when I looked at 
the chronyc output I found this:

pi@SPKR-left:~ $ chronyc tracking
Reference ID    : C0A801FE (192.168.1.254)
Stratum : 4
Ref time (UTC)  : Fri Feb 05 18:50:42 2021
System time : 0.03940 seconds fast of NTP time
Last offset : +0.11845 seconds
RMS offset  : 0.000603218 seconds
Frequency   : 6.857 ppm fast
Residual freq   : +0.000 ppm
Skew    : 0.059 ppm
Root delay  : 0.039830066 seconds
Root dispersion : 0.003487853 seconds
Update interval : 535.4 seconds
Leap status : Normal

Notice the reported update interval of 535 seconds. But my server line includes 
the directives:

minpoll 2 

Re: [chrony-users] chrony not observing maxpoll - bug?

[Bill Unruh]

As I mentioned, look in the measurement.log file to see how often the system
is being polled.

It is possible that the polls get so bad (or non-existant) that it keeps
trying to get 8 filter values to filter.




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, 5 Feb 2021, Charles Laub wrote:


Background: I need to keep several machines well synchronized to my local NTP 
reference. This is for audio work, where playback needs to be tightly 
synchronized
between multiple computers. I previously used NTP for many years for this, but 
have recently switched to chrony to take advantage of its time smoothing and
filtering capabilities. I have a local "server" in my basement where the temp 
remains constant. It's a stable reference for other computers in my home. My
machines only poll only this one sever.

On various Linux clients, I am experiencing the following issue:

Chrony works as expected. Synchronization is achieved to high precision, e.g. 
tens to few hundred microseconds.


For a local chrony that is not good. The sync should be a few 10s not 100s of
microseconds.


I use a fixed polling interval by setting minpoll and maxpoll to e.g. 2
To keep track of what is going on I print out the last offset every 60 seconds 
in an ssh terminal session
I have noticed sometimes that this value gets "stuck". Here is some example 
output:
Last offset : +0.001239868 seconds
Last offset : -0.001022636 seconds
Last offset : +0.000342921 seconds
Last offset : -0.000313532 seconds
Last offset : -0.001234458 seconds
Last offset : -0.001234458 seconds
Last offset : -0.000906603 seconds
Last offset : -0.000906603 seconds
Last offset : -0.36374 seconds
Last offset : -0.000354126 seconds
Last offset : -0.000354126 seconds
Last offset : -0.10771 seconds
Last offset : -0.10771 seconds
Last offset : -0.10771 seconds
Last offset : -0.10771 seconds
Last offset : -0.000411757 seconds
Last offset : -0.000411757 seconds
Last offset : -0.000411757 seconds


Clearly if the time is a hundred sec, the offsets will repeat since they have
not been updated. 


It dawned on me later that this should not be happening, and when I looked at 
the chronyc output I found this:
pi@SPKR-left:~ $ chronyc tracking
Reference ID    : C0A801FE (192.168.1.254)
Stratum : 4
Ref time (UTC)  : Fri Feb 05 18:50:42 2021
System time : 0.03940 seconds fast of NTP time
Last offset : +0.11845 seconds
RMS offset  : 0.000603218 seconds
Frequency   : 6.857 ppm fast
Residual freq   : +0.000 ppm
Skew    : 0.059 ppm
Root delay  : 0.039830066 seconds
Root dispersion : 0.003487853 seconds
Update interval : 535.4 seconds
Leap status : Normal

Notice the reported update interval of 535 seconds. But my server line includes 
the directives:
minpoll 2 maxpoll 2 iburst filter 8
The poll interval should remain at 2, and with filter=8 the poll should be 
reported every 32 seconds. 535 is certainly not the same as 32, so I suspect a 
bug.

This machine (Pi 4) is running chrony version 3.4, and another (an Intel box) 
is running 3.5. Both show an increase in the poll interval above 32 seconds in
chronyc. When this happens, the synchroncity becomes relatively poor so I would 
like to find a way to fix this problem if possible.


I suspect it is a server problem, not a client chrony problem.



Let me know if there is some other info I can post that might be useful.


The measurement logs would probably help-- but just an exerpt, not the whole
log. See if the polls really are every 4 sec and if the result is not
discarded for some reason. (the tests 123 567 ABCD should all be 1 for a good
sample)



Thanks,

-Charlie

RE: [chrony-users] chrony not observing maxpoll - bug?

[Bill Unruh]

Hm. I did not know about the filter option. If you look in
/var/log/chrony/measurements.log file you should see the servers being polled
every 4 sec, but then the clock (2^2 * 8 =32 sec) only querying the input
every 32 sec, as you say is expected. Look at that measurement.log ( or enable
it if you are not already doing so) to see what happens to the polling as teh
time increases. Ie, is the other machine poll interval still 4 sec or is  it 
what
is increasing.




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 Feb 2021, Charlie Laub wrote:



I am still experiencing this problem and I am at a loss as to why. Perhaps I am 
not understanding what “update interval” means? I assume that if I have maxpoll 
=
minpoll = N the update interval will be the poll interval times the filter 
length, and should not change? Is that correct?

 

Below is another example of output that I generated by printing out a selection 
of data from chronyc tracking. You can see the update interval increases from 32
seconds (expected value) to 182. I am polling a single server using these 
directives:

server 192.168.1.254 minpoll 2 maxpoll 2 filter 8 xleave

 

Update interval : 32.5 seconds Last offset : +0.003051660 seconds Frequency : 
9.270 ppm fast

Update interval : 32.5 seconds Last offset : +0.82686 seconds Frequency : 
21.085 ppm fast
Update interval : 32.4 seconds Last offset : -0.000444030 seconds Frequency : 
6.399 ppm fast
Update interval : 32.5 seconds Last offset : +0.000194910 seconds Frequency : 
3.351 ppm fast
Update interval : 32.3 seconds Last offset : +0.000217533 seconds Frequency : 
3.894 ppm fast
Update interval : 36.5 seconds Last offset : -0.002731794 seconds Frequency : 
4.726 ppm fast
Update interval : 32.5 seconds Last offset : +0.000301728 seconds Frequency : 
1045 ppm fast
Update interval : 32.4 seconds Last offset : +0.000134872 seconds Frequency : 
3.236 ppm fast
Update interval : 32.5 seconds Last offset : +0.000149569 seconds Frequency : 
4.055 ppm fast
Update interval : 32.4 seconds Last offset : -0.001271996 seconds Frequency : 
0.241 ppm fast
Update interval : 36.5 seconds Last offset : +0.000269099 seconds Frequency : 
6.121 ppm fast
Update interval : 36.5 seconds Last offset : +0.000269099 seconds Frequency : 
6.121 ppm fast
Update interval : 121.6 seconds Last offset : -0.000647312 seconds Frequency : 
5.888 ppm fast
Update interval : 121.6 seconds Last offset : -0.000647312 seconds Frequency : 
5.888 ppm fast
Update interval : 121.6 seconds Last offset : -0.000647312 seconds Frequency : 
5.888 ppm fast
Update interval : 178.6 seconds Last offset : -0.000680431 seconds Frequency : 
5.881 ppm fast
Update interval : 178.6 seconds Last offset : -0.000680431 seconds Frequency : 
5.881 ppm fast
Update interval : 178.6 seconds Last offset : -0.000680431 seconds Frequency : 
5.881 ppm fast
Update interval : 182.6 seconds Last offset : +0.000140453 seconds Frequency : 
6.125 ppm fast
Update interval : 182.6 seconds Last offset : +0.000140453 seconds Frequency : 
6.125 ppm fast
Update interval : 182.6 seconds Last offset : +0.000140453 seconds Frequency : 
6.125 ppm fast
Update interval : 174.6 seconds Last offset : -0.26348 seconds Frequency : 
6.119 ppm fast
Update interval : 174.6 seconds Last offset : -0.26348 seconds Frequency : 
6.119 ppm fast

 

 

From: Charles Laub 
Sent: Friday, February 5, 2021 2:42 PM
To: chrony-users@chrony.tuxfamily.org
Subject: [chrony-users] chrony not observing maxpoll - bug?

 

Background: I need to keep several machines well synchronized to my local NTP 
reference. This is for audio work, where playback needs to be tightly 
synchronized
between multiple computers. I previously used NTP for many years for this, but 
have recently switched to chrony to take advantage of its time smoothing and
filtering capabilities. I have a local "server" in my basement where the temp 
remains constant. It's a stable reference for other computers in my home. My
machines only poll only this one sever.

 

On various Linux clients, I am experiencing the following issue:

 

Chrony works as expected. Synchronization is achieved to high precision, e.g. 
tens to few hundred microseconds.

I use a fixed polling interval by setting minpoll and maxpoll to e.g. 2

To keep track of what is going on I print out the last offset every 60 seconds 
in an ssh terminal session

I have noticed sometimes that this value gets "stuck". Here is some example 
output:

Last offset : +0.001239868 seconds
Last offset : -0.001022636 seconds
Last offset : +0.000342921 seconds
Last offset : -0.000313532 seconds
Last offset : -0.001234458 seconds
Last offset : -0.001234458 seconds
Last offset : -0.000906603 seconds
Last offset : 

Re: [chrony-users] chrony not observing maxpoll - bug?

[Bill Unruh]

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, 5 Feb 2021, Charles Laub wrote:


Background: I need to keep several machines well synchronized to my local NTP 
reference. This is for audio work, where playback needs to be tightly 
synchronized
between multiple computers. I previously used NTP for many years for this, but 
have recently switched to chrony to take advantage of its time smoothing and
filtering capabilities. I have a local "server" in my basement where the temp 
remains constant. It's a stable reference for other computers in my home. My
machines only poll only this one sever.

On various Linux clients, I am experiencing the following issue:

Chrony works as expected. Synchronization is achieved to high precision, e.g. 
tens to few hundred microseconds.
I use a fixed polling interval by setting minpoll and maxpoll to e.g. 2


Not a great idea. This will mean that the chrony has a hard time figuring out
what frequency it is supposed to run at. (it will be noisy.) There is an
optimal poll interval at which both the offset and the frequency are "best",
and it is a lot longer than poll 2.


To keep track of what is going on I print out the last offset every 60 seconds 
in an ssh terminal session
I have noticed sometimes that this value gets "stuck". Here is some example 
output:


That is not stuck. That is an oscillation. If you let the poll interval be
longer I suspect you would get much better behavious. Which a bunch of
computers in your own house, with a reasonable connectivity (and I would
suggest wired connection between the machines, not wireless) you should get
more like a few microseconds after it settles down.


Last offset : +0.001239868 seconds
Last offset : -0.001022636 seconds
Last offset : +0.000342921 seconds
Last offset : -0.000313532 seconds
Last offset : -0.001234458 seconds
Last offset : -0.001234458 seconds
Last offset : -0.000906603 seconds
Last offset : -0.000906603 seconds
Last offset : -0.36374 seconds
Last offset : -0.000354126 seconds
Last offset : -0.000354126 seconds
Last offset : -0.10771 seconds
Last offset : -0.10771 seconds
Last offset : -0.10771 seconds
Last offset : -0.10771 seconds
Last offset : -0.000411757 seconds
Last offset : -0.000411757 seconds
Last offset : -0.000411757 seconds

It dawned on me later that this should not be happening, and when I looked at 
the chronyc output I found this:
pi@SPKR-left:~ $ chronyc tracking
Reference ID    : C0A801FE (192.168.1.254)
Stratum : 4
Ref time (UTC)  : Fri Feb 05 18:50:42 2021
System time : 0.03940 seconds fast of NTP time
Last offset : +0.11845 seconds
RMS offset  : 0.000603218 seconds
Frequency   : 6.857 ppm fast
Residual freq   : +0.000 ppm
Skew    : 0.059 ppm
Root delay  : 0.039830066 seconds


That is huge in your own house.


Root dispersion : 0.003487853 seconds
Update interval : 535.4 seconds
Leap status : Normal

Notice the reported update interval of 535 seconds. But my server line includes 
the directives:
minpoll 2 maxpoll 2 iburst filter 8
The poll interval should remain at 2, and with filter=8 the poll should be 
reported every 32 seconds. 535 is certainly not the same as 32, so I suspect a 
bug.

This machine (Pi 4) is running chrony version 3.4, and another (an Intel box) 
is running 3.5. Both show an increase in the poll interval above 32 seconds in
chronyc. When this happens, the synchroncity becomes relatively poor so I would 
like to find a way to fix this problem if possible.

Let me know if there is some other info I can post that might be useful.

Thanks,

-Charlie

Re: [chrony-users] Large ppm clock slew rate

[Bill Unruh]

Thanks for the tick rate adjustment pointer.   ntpd doesn't adjust the tick 
value, as far as I
know.  The ntp.org NTP distribution does include the tickadj utility, which 
pokes /dev/kmem to
adjust the tick value.

The context is the International Space Stations (see thread at
http://lists.febo.com/pipermail/time-nuts_lists.febo.com/2021-January/102525.html)


Weird. Now ntp does not do anything above 500PPM, so it may just be that the
ISS computer clock is badly calibrated so that the rest tick rate is out by
say 1000PPM, and initialy it tries to gradually increase the PPM to 500, and
then gives up.  Ie, it might be interesting to set up a machine on the ground
where the tick rate is out by say 1000 PPM, and see if it behaves the same
way. Certainly chrony should be able to fix this, by adjusting the tick rate. 
It is weird that it drift rate increases with time.  Maybe a bug in ntpd?

I assume that the steps are offset steps introduced by ntp stepping the clock.
Why it would do so at different offsets is also strange.

ntp does not try to separately adjust the drift rate. It assumes that if it
tries to adjust the time offset by changing the drift, the rate of the clock
will automatically go to 1s/s.

The externally observed frequency offset gradually increases from -500 to -1500 
ppm with a
repeating pattern.   This is bizarre, see the offset graph.  
If the cause can be determined, it may be correctable with ntpd or perhaps 
switching to chrony.


You might be able to manually adjust the tick rate with adjtimex(8) to bring
the drift of the clock into ntpd range and then normal ntpd would take over. 
Or use chrony which would do that automatically. But I guess the problem is

that changing (ntpd->chrony) is wrapped up in far more bureacracy than is
change like a manual resetting of the tick rate. 
But firstly, one needs to get a system on earth behaving the same way so one

can try experiments on it. Teh first one would be to manually adjust the tick
rate on some earthbound system so that the uncorrected drift is say 1000PPM
and then start up ntpd and see if it behaves similarly.



This particular host is running ntpd 4.2.8, so this isn't the right email list 
for detailed ntpd
discussions.


On Tue, Jan 19, 2021 at 12:06 PM Bill Unruh  wrote:
  If your clock is out that badly then there is something very wrong with 
your
  onboard clock or in the calibration of the clock initially

  The linux kernel has two time adjustments, a fine on ( which has the 
500PPM
  limit) and a course one( which has the 1/10 sec/sec limit) Chrony uses 
both.
  Ntpd just uses the fine one.

  chrony measures the offset of the clock wrt a clock source and runs a 
linear
  fit on the last N offset readings. It adjusts the clock rate to gradually
  bring the rate to 1s/s with respect to standard (ewxternal ntp source(s).
  The linear fit is tested to see if a linear fit is a reasonable fit to the
  offsets. If not, it decreases N, the number of offsets used, until the 
fit is
  reasonable (Not too many differences between the offsets and the linear 
fit)  with a
  single sign in a row).
  At worst it uses just three offsets to fit to.  It grows N ( by one at a 
time)
  until the linear fit goes bad, or until a maximum value of N is reched (I
  think it is 64).

  The documentation for chrony describes a lot of this. Then there is the 
source
  code itself. Because of the linear fit, it can determine the residual 
offset
  and the rate much more quickly and accurately than does ntp, with chrony 
able
  to get sometimes more than a factor of 10 improvement over ntpd.
  ntpd just uses a simple feedback loop.
  (Note that when chrony alters the rate or the offset of the clock, it 
adjusts
  the whole history of offsets it uses to fit by that change in offset and 
rate,
  to keep the past data relevant to the current running of the clock.
  )


  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 Mon, 18 Jan 2021, Steven Sommars wrote:

  >
  > I have a Linux installation which may require clock slew rate > 500 
ppm, which
  exceeds normal
  > adjustimex limits.  Chrony lists a 10 ppm maximum slew rate.  How 
is that
  done?
  >
  > Is there a document that describes chrony's clock discipline algorithm?
  >
  >

Re: [chrony-users] Large ppm clock slew rate

[Bill Unruh]

If your clock is out that badly then there is something very wrong with your
onboard clock or in the calibration of the clock initially

The linux kernel has two time adjustments, a fine on ( which has the 500PPM
limit) and a course one( which has the 1/10 sec/sec limit) Chrony uses both.
Ntpd just uses the fine one.

chrony measures the offset of the clock wrt a clock source and runs a linear
fit on the last N offset readings. It adjusts the clock rate to gradually
bring the rate to 1s/s with respect to standard (ewxternal ntp source(s). 
The linear fit is tested to see if a linear fit is a reasonable fit to the

offsets. If not, it decreases N, the number of offsets used, until the fit is
reasonable (Not too many differences between the offsets and the linear fit)  
with a single sign in a row).
At worst it uses just three offsets to fit to.  It grows N ( by one at a time)
until the linear fit goes bad, or until a maximum value of N is reched (I
think it is 64).

The documentation for chrony describes a lot of this. Then there is the source
code itself. Because of the linear fit, it can determine the residual offset
and the rate much more quickly and accurately than does ntp, with chrony able
to get sometimes more than a factor of 10 improvement over ntpd.
ntpd just uses a simple feedback loop.
(Note that when chrony alters the rate or the offset of the clock, it adjusts
the whole history of offsets it uses to fit by that change in offset and rate,
to keep the past data relevant to the current running of the clock.
)


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 Mon, 18 Jan 2021, Steven Sommars wrote:



I have a Linux installation which may require clock slew rate > 500 ppm, which 
exceeds normal
adjustimex limits.  Chrony lists a 10 ppm maximum slew rate.  How is that 
done?

Is there a document that describes chrony's clock discipline algorithm?

Re: [chrony-users] Large ppm clock slew rate

[Bill Unruh]

t to add: If you look at the man page
man 8 adjtimex
(you need to install the adjtimex package) there are two adjustments.
One is the tick adjustment. Each incriment changes the tick time ( the time
the computer assumes a tick of the clock is worth ) by about 100PPM.

 -t val, --tick val
  Set the number of microseconds that should be added to the system 
time for each
  kernel tick interrupt.  For a kernel with USER_HZ=100, there are 
supposed to be 100
  ticks per second, so val should be close to 1.  Increasing 
val by 1 speeds up
  the system clock by about 100 ppm, or 8.64 sec/day.  tick must be 
in the range
  90/USER_HZ...110/USER_HZ.  If val is rejected by the 
kernel, adjtimex will
  determine the acceptable range through trial and error and print 
it.  (After
  completing the search, it will restore the original value
The other is the frequency
-f newfreq, --frequency newfreq
  Set the system clock frequency offset to newfreq.  newfreq can be 
negative or
  positive, and gives a much finer adjustment than the --tick 
switch.  When
  USER_HZ=100, the value is scaled such that newfreq = 65536 speeds 
up the system
  clock by about 1 ppm, or .0864 sec/day.  Thus, all of these are 
about the same:
   --tick  9995 --frequency  32768000
   --tick 1 --frequency   6553600
   --tick 10001 --frequency 0
   --tick 10002 --frequency  -6553600
   --tick 10005 --frequency -32768000
  To see the acceptable range for newfreq, use --print and look at 
"tolerance", or
  try an illegal value (e.g. --tick 0).

This is the one that is about plus or minus 500PPM So, chrony uses both tick
and frequency to adjust the rate of the clock, frequency for fine adjustment,
tick for coarse.
I believe ntpd only uses the frequency adjustment.


On Mon, 18 Jan 2021, Steven Sommars wrote:



I have a Linux installation which may require clock slew rate > 500 ppm, which 
exceeds normal
adjustimex limits.  Chrony lists a 10 ppm maximum slew rate.  How is that 
done?

Is there a document that describes chrony's clock discipline algorithm?

RE: [chrony-users] chronyd.service doesn't have Restart=on-failure?

[Bill Unruh]

But I think the lines:

Restart=on-failure
RestartSec=30s

Should be added in the [Service] section. If chronyd fails for any reason, 
given how important time is, I can't think why it wouldn't try to restart.



Well, if, due to some bug in chrony or bad configuration, chrony dies, then it
is liable to die again and again and again. Having a program do that is not a
good idea. Rather the sysadmin needs to fix things. Remember that the local
clock is still running, so that time is not a complete disaster. 
If you really wanted to you could have a cron job run every minute, and if

chrony is not running, then restart it (and send the sysadmin an email saying
it had happened).

--
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] Refclock Integration Advice

[Bill Unruh]

On Mon, 30 Nov 2020, Miroslav Lichvar wrote:


On Mon, Nov 30, 2020 at 03:03:10PM +, Chang, Benjamin wrote:

So I managed to switch it to a 50% duty cycle PPS, and it appears to take every 
pulse now. The LastRX floats between 0 and 2 (seemed like 20 us is too short a 
pulse).

However, now when I look at the measured offsets, it seems to greatly vary from 
100s of ns to 10s of us. Shouldn't it be consistent? According to the datasheet 
of my PPS (the syncserver S650), it should have ~15 ns accuracy and resolution. 
When I scoped it on an oscilloscope, it was consistent and not varying.


Almost certainly problems with the interrupt handling by the computer. It
takes a while for the operating system to get to the interrupt, if other
things (disk reads, etc) are hogging the interrupt system. 20us seems a bit
long, but it will depend on your system. 


Here is my conf file setup
My ntp server setting: minpoll -6 maxpoll -6


That still makes absolutely no sense. What in the world do you expect to
change in 1/64 of a second. Certainly there is no new time signals coming from
the gps unit.


My PPS: poll 0 prefer trust pps width 0.5


If you use a serial port for the PPS, the stability will depend on how
stable is the interrupt delay. A stability in tens of microseconds is
not unusual. You may get better results if you disable all
power-saving states and set a fixed frequency for the CPU.

If you increase the chrony poll to 3 or 4, the PPS samples will be
filtered using a median filter and that should help with the outliers.


--
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] ntpdata as normal user

[Bill Unruh]

I currently need to change the permission of both /run/chrony and
/run/chrony/chronyd.sock to be able to access it from a non-root,
non-_chrony user.


Would it work if /var/run/chrony had permissions 0775 and the user was
in the chrony group?

Maybe chronyc could have an option to specify the location of its
socket and let the user put it in a hidden directory where chronyd is
allowed to write? Too risky?


That does sound too risky to me. This is security through obscurity, and
rarely lasts past its first test by some hacker.

--
To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org 
with "unsubscribe" in the subject.
For help email chrony-users-requ...@chrony.tuxfamily.org 
with "help" in the subject.

Trouble?  Email listmas...@chrony.tuxfamily.org.

Re: [chrony-users] Chrony server transition behavior

[Bill Unruh]

On Mon, 16 Nov 2020, Antoine Sgambato wrote:


I am trying to understand how chrony transition from a time server.

Lets consider a Chrony client synchronized with a sole and unique server. 
Synchronization is established with no problem.
Now I remove this server from my chrony configuration (with the chronyc delete 
command). I expect my Chony client to become either in local or un-synchronized 
state (depending on whether the local mode has been enabled or not).



And it does so, but it takes some time : As soon as the server is deleted from my config, 
I have a log that says "Can't synchronise: no selectable sources" (and chronyc 
sources returns an empty list) but the tracking command says it is still synchronized 
with the server for well other than 2 hours before switching to the local mode (in my 
case).


Of course. It is not going to consider itself unsynchronized as soon as the
source disappears. It has no idea why the source disappeared. It is set up to
run for possibly hours before it starts to wander away from UTC. Note that if
your poll is 10, that is 2^10 sec which is 1/3 of an hour, and it would
certainly feel itself to be fine for a few missed periods ( ie hours). Chrony
is NOT a parrot, simply repeating what it got from its sources. It is a way of
disciplining your local clock so that its time is the same as UTC. AFter a
while, of not getting any updates it will finally decide that its own time has
possibly drifted (depending on the uncertainties of the rate and of the time)
far enough away from UTC that it no longer trusts its own time.


I suspect that, as the synchro was well established (drifts parameters have 
been calculated and stored in the drift file), Chrony considers itself as still 
synchronized with a source for some time even if the is no more communications 
with this source.

Is this reasoning correct? and are there some configuration parameters that 
affect this delay?


Yes, the reasoning is correct. 
What is it that you are trying to do, or test?




Thank you for any clarification!

Antoine.
--
To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org
with "unsubscribe" in the subject.
For help email chrony-users-requ...@chrony.tuxfamily.org
with "help" in the subject.
Trouble?  Email listmas...@chrony.tuxfamily.org.



--
To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org 
with "unsubscribe" in the subject.
For help email chrony-users-requ...@chrony.tuxfamily.org 
with "help" in the subject.

Trouble?  Email listmas...@chrony.tuxfamily.org.

Re: [chrony-users] PPS Synchronization Verification

[Bill Unruh]

On Mon, 2 Nov 2020, Miroslav Lichvar wrote:


On Mon, Nov 02, 2020 at 12:24:32PM +, Chang, Benjamin wrote:

The PPS signal is coming from the NTP server (it's a syncserver S650) and is 
connected via a 232 line. I essentially did this 
https://www.crc.id.au/2016/09/24/adding-a-pps-source-to-ntpd/ but switched the 
ntpd kernel with the chrony kernel. Should I set an offset of .2 for the 
PPS?


20 microseconds for an interrupt? That seems pretty high. One tests I ran
about 10 years ago, (sending a timed signal over on the parallel port lines to
the serial port interrupt line) the latency was closer to or less than 1 
microsecond.



Yes, that should make two sources agree with each other. Or, you can
add the opposite correction to the NTP source. Without a trusted time
source it's difficult to tell which one is more accurate. If you
enabled hardware timestamping, I'd probably trust more the NTP source.

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



--
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] reachability cycling between 377 to 000

[Bill Unruh]

All:

 

If I monitor the output from 'chronyc sources', I see the reachability status
change regularly from "377" to "000" and back again. Is this a known problem or
a wrong / incomplete configuration?

 

After starting 'chronyd', the reachablilty goes from 0 to 377 as expected. 12
minutes (+/-1 poll interval) after "377", reachability starts dropping every 16
s poll interval (376, 374, 370, ...) down to 000. There it stays for 12 minutes,
at which point reachability starts ascending (000, 003, 007, ...) back to 377.
The process then repeats. Typical data from ‘chronyc -s’ is shown below.


That means that chrony stopped being able to reach the source. It is a byte
where the bits are moved over (to the high bit) and the lowest bit is replaced
by 1 if the source was reached and by 0 if not. Ie, the lowest bit always
shows the reachability of the source at the last attempt, the next lowest the
reachability on the second last attempt, etc.



 

I'm using a Raspberry Pi 4B and Uputronics GPS HAT (uBlox 8) with 'gpsd'
(versions shown below). I built it following the instructions on the NTPSEC
documentation page, “Stratum-1-Microserver HOWTO”. This includes stripping
non-essential (for NTPSEC) services. Details, including ‘ps’ output for
‘chronyd’ and ‘gpsd’ are below.


Sounds like a problem with gpsd. Or with the card.



 

'cgps -s' shows nothing obviously wrong to my eye.  I have a cheapo puck antenna
in the window with mostly south exposure. Capturing NMEA GGA sentences as close
as possible to the reachability changes always shows a lock at that time (field
5, "FS Fix Status).

 

This setup runs 'ntpsec' as expected, with perhaps a little more jitter than I'd
like. There is no change in reachability once 377 is achieved at startup.

 

Thanks for any ideas for fixing or further troubleshooting.

 

-wis

 

Test Setup

 

RPI 4B with 2GB RAM and latest firmware, Uputronics GPS HAT (uBlox 8)

---

wis@raspberrypi:~ $ cat /proc/cpuinfo | perl -ane 'next if( !
/(Revision|Hardware)/m); print'

Hardware  : BCM2711

Revision  : b03111

wis@raspberrypi:~ $ uname -a

Linux raspberrypi 5.4.51-v7l+ #1333 SMP Mon Aug 10 16:51:40 BST 2020 armv7l
GNU/Linux

wis@raspberrypi:~ $ chronyd -v

chronyd (chrony) version 3.5.1 (+CMDMON +NTP +REFCLOCK +RTC +PRIVDROP -SCFILTER
-SIGND +ASYNCDNS -SECHASH +IPV6 -DEBUG)

wis@raspberrypi:~ $ gpsd -V

gpsd: 3.21.1~dev (revision release-3.21-191-ge80e4bd75)

wis@raspberrypi:~ $ sudo rpi-eeprom-update

BCM2711 detected

Dedicated VL805 EEPROM detected

BOOTLOADER: up-to-date

CURRENT: Thu 03 Sep 2020 12:11:43 PM UTC (1599135103)

LATEST: Thu 03 Sep 2020 12:11:43 PM UTC (1599135103)

FW DIR: /lib/firmware/raspberrypi/bootloader/critical

VL805: up-to-date

CURRENT: 000138a1

LATEST: 000138a1

wis@raspberrypi:~ $ ps -aux | grep sbin/gpsd | grep -v grep

nobody 426  0.1  0.0  11776  1664 ?    S
?? ??┐┌──Seen 24/Used 11┐


│ Time:    2020-10-16T00:45:08.000Z (18)││ PRN  Elev   Azim   SNR 
Use │

│ Latitude:     N   ││GP 3  64.0  177.0  25.0  
Y  │

│ Longitude:    W   ││GP 4  71.0  325.0  33.0  
Y  │

│ Alt (HAE, MSL):    406.827,    482.211 ft ││GP 6  21.0  301.0  31.0  
Y  │

│ Speed: 0.01 mph   ││GP 7  13.0  231.0  29.0  
Y  │

│ Track (true, var):    12.3,  14.7 deg ││GP 9  35.0  290.0  28.0  
Y  │

│ Climb: 0.00 ft/min    ││GP    16  37.0  125.0  37.0  
Y  │

│ Status: 3D DGPS FIX (2 secs)  ││GP    22  42.0  166.0  29.0  
Y  │

│ Long Err  (XDOP, EPX):  0.51, +/-  6.4 ft ││GP    26  39.0   75.0  30.0  
Y  │

│ Lat Err   (YDOP, EPY):  0.65, +/-  8.7 ft ││GP    31  14.0   52.0  21.0  
Y  │

│ Alt Err   (VDOP, EPV):  1.41, +/- 21.9 ft ││GL    71  44.0  110.0  21.0  
Y  │

│ 2D Err    (HDOP, CEP):  0.88, +/- 13.4 ft ││GL    73  43.0   41.0  13.0  
Y  │

│ 3D Err    (PDOP, SEP):  1.66, +/-  138 ft ││GP 1   2.0  198.0   0.0  
N  │

│ Time Err  (TDOP):   0.87  ││GP 2   1.0  338.0   0.0  
N  │

│ Geo Err   (GDOP):   1.88  ││SB    46  39.0  189.0   0.0  
N  │

│ ECEF X, VX:   -2505536.420 m    0.010 m/s ││SB    48  38.0  194.0   0.0  
N  │

│ ECEF Y, VY:   -3848833.310 m   -0.020 m/s ││SB    51  37.0  158.0   0.0  
N  │

│ ECEF Z, VZ:    4411330.600 m    0.000 m/s ││GL    65  31.0  317.0   0.0  
N  │

│ Speed Err (EPS):   +/-  1.0 mph   ││GL    72  71.0    n/a   0.0  
N  │

│ Track Err (EPD):   +/-  193 deg   ││GL    74  73.0  155.0   0.0  
N  │

│ Time offset:    0.471591566 s ││GL    75  19.0  199.0   0.0  
N  │

│ Grid Square:      ││GL    81   8.0  345.0   0.0  
N  │

└──

?? ??┘└More...──┘


 

Re: [chrony-users] help - UTC time of PPS pulses

[Bill Unruh]

Unless the card is a many pulses per second (eg 5 per second) then the pulse
is on exactly the UTC second to within a few nanoseconds (unless you have a
really crappy gps card)
Note that the pulse has a leading and trailing edge. If you use the trailing
edge then the time will be out by up to milliseconds from UTC, and have a
large fluctuation. If the card is a multi pulses per second, then the time
will be at exactly 1/n second ( eg 0 , .2,.4,.6,.8) to within a few
nanoseconds. There is nothing in the stream which would displace this by
milliseconds.



On Wed, 14 Oct 2020, Yoed Stavi wrote:


Hi Miroslav,
Thank you for your comments.

We have chronyd configured with a reference NTP server and a PPS in addition.
In my understanding this configuration sets the time according to the NTP 
server and then maintains the frequency with the PPS.
I was under the assumption that the GPS pulses are not precisely aligned with 
whole UTC seconds.
I need to know the offset between the pulses and the UTC seconds in order to 
create timestamps that are relative to the pulses rather than UTC seconds.
In the refclocks log I see the following:
2020-10-14 08:47:09.03 PPS 7 N 1 -3.747000e-06 -3.382498e-06  2.200e-08

So now I'm thinking: if each of these lines is a GPS pulse, maybe my assumption 
is wrong and the pulses are aligned with UTC seconds.
And possibly the offset that I've been measuring is due to transmission delay 
of the ASI card.

Highly unlikely. That might be on the microsecond level, not millisecond. The
interrupt handler could well introduce problems at the microsecond level.



Thank you,
 Yoed.


-Original Message-
From: Miroslav Lichvar 
Sent: Tuesday, 13 October 2020 13:30
To: chrony-users@chrony.tuxfamily.org
Subject: [EXTERNAL] Re: [chrony-users] help - UTC time of PPS pulses

On Tue, Oct 13, 2020 at 10:03:10AM +, Yoed Stavi wrote:

Hi,

I use Chrony as our NTP client and also for PPS synchronization.
This works great.
The same server creates a DVB-T transport (MPEG-2 TS with MIP packets). The 
DVB-T protocol includes timestamps that should be relative to GPS pulses.
Since the DVB-T software doesn't know when the GPS pulses are (only Chrony 
knows that), I set the timestamps to be relative to whole UTC seconds instead 
of GPS pulses.

I would like to improve by knowing the offset between GPS pulses and UTC 
seconds as it is measured by Chrony  (from my measurements the result should be 
between 230-250 milliseconds).


I'm not sure if I understand your goal correctly. You have chronyd configured to 
synchronize the system clock to UTC using a PPS signal coming from a GPS receiver and you 
want to measure the offset between the PPS and UTC? That would be the offset that chronyd 
is minimizing, i.e. it should be close to zero. The measurements can be reported by the 
"chronyc sources" command, and also in the refclocks log if enabled.

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


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