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
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,
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
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
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
...@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
, 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
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,
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
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
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
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 __|_
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 _|___
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,
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 |
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,
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
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
as 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 a
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,
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
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
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
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
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
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
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
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,
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
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
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
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
en
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 l
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
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
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
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,
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
: +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
--
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
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
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,
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
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
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
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
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
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
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:
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:
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
' 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
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 (
oller 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
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
__|_ 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
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
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
. 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
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
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
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
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
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
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
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
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,
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:
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
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,
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
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
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
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
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,
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,
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
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
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
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
thesis.
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
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
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
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
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
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
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
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 _|___
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
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,
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 cl
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
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
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
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
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
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
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
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
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
1 - 100 of 374 matches
Mail list logo
