On 19/02/2016 03:08, Bryan Christianson wrote:
My understanding is that chrony.ttyAMA0.sock is a socket
created by chronyd and listened to by chronyd When gpsd
starts, it checks to see if the socket exists and writes
the PPS data to it.
Isn't that backwards? How would gpsd know what socket to
On 18/02/2016 22:48, Deven Hickingbotham wrote:
$cat /sys/class/pps/pps0/assert
1455831692.018636856#178
Are you seeing those?
Yes, but just one timestamp per execution:
pi@gps ~ $ cat /sys/class/pps/pps0/assert
1455835119.289108505#4272
pi@gps ~ $ cat /sys/class/pps/pps0/assert
1455835154
On 16/10/2015 15:04, Steven Liegaux wrote:
PS: Sorry for my English level, it's not my mother tongue
at all.
It was perfect. Better than most native English speakers I
encounter on the internet, actually.
Tom
--
To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org
with "unsubscri
On 05/10/2015 10:38, Nuno Gonçalves wrote:
On Mon, Oct 5, 2015 at 10:31 AM, Tomalak Geret'kal wrote:
Timezone changes don't (shouldn't!) change the time. Timezone settings
(including DST offsets) are applied when generating a human-readable
timestamp, but do not affect the actua
On 05/10/2015 10:25, Nuno Gonçalves wrote:
I didn't tought of the possibility of the RTC being in local time and
having a offline backward change, obviously.
For similiar reasons you have the possibility of the user changing the
timezone under another OS.
I don't think using the compile time i
On 02/07/2015 22:50, Don Salvin Lists wrote:
Newbie(?) question:
I'm trying to build and install chrony on an i386 CentOS
6.6 machine.
What am I missing?
Thanks,
=Don
Hi Don,
A quick Google search shows that makeinfo comes from the
"texinfo" package, so install that:
sudo yum install
On 19/04/2015 09:42, Pratik Pawar wrote:
Hi All,
I have one strange question about chrony.
I am using chrony to keep embedded board system time
in sync. When GPS receiver is connected to board, It can
able to sync system time with very negligible deviation.
The reference clock for c
On 05/04/2015 08:49, Olivier Delbeke wrote:
Hi Bill,
Thanks a lot. I will dig into the code and try to
understand exactly what happens and how I could use
chronyd in the best possible way. Then, I will propose it
to AGL.
You said ""But yes, you can tell it to jump the clock if
it is far off
On 26/10/2014 00:28, Dominik Auras wrote:
Hello!
I am trying to setup chrony for my new GPS. Unfortunately,
chrony won't select any source if I enable both the NMEA
and PPS source. I bet that my configuration is wrong ...
but it is unclear to me how to configure the PPS.
Could you maybe exp
On 03/12/2013 20:11, Chris Dore wrote:
Do you know what time Chrony serves up when no remote
servers are available and the 'local' option is specified?
I assumed, maybe falsely, that it was using the local
system time. So perhaps the support I'm looking for
already exists, but not enabled at t
On 03/12/2013 01:29, Bill Unruh wrote:
[snip]
I concede all of that.
Though, once you have figured out what you want to happen,
it's still worth testing.
Tom
--
To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org
with "unsubscribe" in the subject.
For help email chrony-users-req
On 03/12/2013 01:16, Bill Unruh wrote:
On Tue, 3 Dec 2013, Tomalak Geret'kal wrote:
On 03/12/2013 00:58, Bill Unruh wrote:
> > In my test setup I have the master server's clock
set back about 3 hours > and Chrony appears to be
working great and is moving time towards w
On 03/12/2013 00:58, Bill Unruh wrote:
In my test setup I have the master server's clock set
back about 3 hours and Chrony appears to be working great
and is moving time towards what is reported by the
external NTP servers:
Why? Is this a rediculous test? Why would you expect the
master
On 29/11/2013 18:21, Miroslav Lichvar wrote:
Anyway, it should not be switching sources unless the deviation of the
selected source exceeds the variance of the alternative (or unless the source
has disappeared for a suitable number of poll intervals, probably related to
how long one would expect
On 28/11/2013 20:54, Bill Unruh wrote:
And on further thought, I also concede your point, since
pps does not really
give the fractions of a second either, but just gives the
second mark. You do
need an additional "clock" to actually tell you the
fractions of a second.
Yes...
Anyway, I hope
On 28/11/2013 20:05, Bill Unruh wrote:
On Thu, 28 Nov 2013, Tomalak Geret'kal wrote:
On 28/11/2013 19:11, Bill Unruh wrote:
Is this the nmea time or the PPS time?
What is "PPS time"? PPS provides timing, not time.
In my nomenclature, they are the same. PPS does supply
ti
On 28/11/2013 19:11, Bill Unruh wrote:
Is this the nmea time or the PPS time?
What is "PPS time"? PPS provides timing, not time.
Tom
--
To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org
with "unsubscribe" in the subject.
For help email chrony-users-requ...@chrony.tuxfamily.org
On 31/10/2012 13:57, john.flor...@dart.biz wrote:
In any case, I very much appreciate everyone's effort to
make it better and/or explain the devil in the details.
Thank you all.
It was fun!
On 31/10/2012 13:03, Ed W wrote:
On 31/10/2012 10:36, Tomalak Geret'kal wrote:
On 31/10/2012 10:35, Miroslav Lichvar wrote:
On Wed, Oct 31, 2012 at 10:14:01AM +0000, Tomalak
Geret'kal wrote:
Again, chrony doesn't need the TTL. Caching is handled
by the
resolver.
getaddrinfo(
On 31/10/2012 10:35, Miroslav Lichvar wrote:
On Wed, Oct 31, 2012 at 10:14:01AM +, Tomalak Geret'kal wrote:
Again, chrony doesn't need the TTL. Caching is handled by the
resolver.
getaddrinfo() blocking is a more concrete problem to solve - good
spot.
I don't think getaddr
On 31/10/2012 10:12, Miroslav Lichvar wrote:
On Tue, Oct 30, 2012 at 10:30:45PM +, Tomalak Geret'kal wrote:
I feel like we've been over this sufficiently to solve the problem.
Chrony could near-trivially poll the resolver when required with
such a mechanism being rate limited
12 22:16
On Tue, 30 Oct 2012, Tomalak Geret'kal wrote:
> Chrony does not need to know. The OS's DNS resolver knows. Chrony merely
> needs to use it. This problem was solved decades ago.
Of course the resolver knows. The problem is that chrony does NOT query the
resolver on
- Reply message -
From: "Bill Unruh"
To:
Subject: [chrony-users] hostnames vs. IP address in chrony.conf
Date: Tue, Oct 30, 2012 21:08
On Tue, 30 Oct 2012, Tomalak Geret'kal wrote:
> Bill
>
> It should work the same way as every other piece of network-enabled software
: [chrony-users] hostnames vs. IP address in chrony.conf
Date: Tue, Oct 30, 2012 20:46
On Tue, 30 Oct 2012, john.flor...@dart.biz wrote:
> Bill Unruh wrote on 10/30/2012 15:45:14:
>>
>> On Tue, 30 Oct 2012, Tomalak Geret'kal wrote:
>>
>>> On 30/10/2012 19:21, Bi
On 30/10/2012 19:45, Bill Unruh wrote:
On Tue, 30 Oct 2012, Tomalak Geret'kal wrote:
On 30/10/2012 19:21, Bill Unruh wrote:
On Tue, 30 Oct 2012, Tomalak Geret'kal wrote:
> Could chronyd not be made to pay attention to the TTL
of the IPs it > resolves?
> That would /
On 30/10/2012 19:23, john.flor...@dart.biz wrote:
> Remember that chrony keeps the
> up to the past 64 queries to a server, and must make
sure that all queries to
> the same server remain associated with the same server.
Far easier to use IP
> to make that association. Chrony also keeps info f
On 30/10/2012 19:24, Tomalak Geret'kal wrote:
On 30/10/2012 19:21, Bill Unruh wrote:
On Tue, 30 Oct 2012, Tomalak Geret'kal wrote:
Could chronyd not be made to pay attention to the TTL of
the IPs it resolves?
That would /truly/ be "using IP to make that association".
On 30/10/2012 19:21, Bill Unruh wrote:
On Tue, 30 Oct 2012, Tomalak Geret'kal wrote:
Could chronyd not be made to pay attention to the TTL of
the IPs it resolves?
That would /truly/ be "using IP to make that association".
What is the "TTL of the IPs it resolves"?
On 30/10/2012 19:09, Bill Unruh wrote:
On Tue, 30 Oct 2012, john.flor...@dart.biz wrote:
What strategy does chronyd use to resolve the hostnames
to IP addresses
for its upstream time servers? I'm guessing it does so
once at startup
and then caches the result for all future use. Is that
corr
On 03/09/2012 15:35, Miroslav Lichvar wrote:
On Thu, Aug 23, 2012 at 03:35:56PM +0100, Tomalak Geret'kal wrote:
Hey
My /etc/chrony.conf is owned by an automated tool (of sorts) which
currently has to kill the chrony process and restart it, in order
for chrony to pick up new config when
On 24/08/2012 16:35, Miroslav Lichvar wrote:
On Fri, Aug 24, 2012 at 04:16:18PM +0100, Tomalak Geret'kal wrote:
Me again...
If chrony is tracking /dev/pps0 as a refclock, does it keep this
device open persistently? Or does it close and re-open it for every
poll? Reason I ask is that a sep
Me again...
If chrony is tracking /dev/pps0 as a refclock, does it keep
this device open persistently? Or does it close and re-open
it for every poll? Reason I ask is that a separate process
is seemingly still able to `open("/dev/pps0", O_ACCMODE)`
and even block on pulses with `ioctl` whilst
On 23/08/2012 12:32, Tomalak Geret'kal wrote:
On 23/08/2012 12:20, Tomalak Geret'kal wrote:
Having fixed that, I can now see that the *actual* error
from shmget() (as implied by the SYS_307 line, I guess)
is errno 22 EINVAL (Invalid argument), and *not* 2 (No
file or directory).
Hey
My /etc/chrony.conf is owned by an automated tool (of sorts)
which currently has to kill the chrony process and restart
it, in order for chrony to pick up new config when it's
made. This doesn't feel too robust, since the kill could
theoretically fail and then the restart wouldn't work
e
On 23/08/2012 12:20, Tomalak Geret'kal wrote:
Having fixed that, I can now see that the *actual* error
from shmget() (as implied by the SYS_307 line, I guess) is
errno 22 EINVAL (Invalid argument), and *not* 2 (No file
or directory).
Tom
I've found a discrepancy in the size of t
On 23/08/2012 11:54, Tomalak Geret'kal wrote:
When I remove this bit, the adjtimex() issue progresses to
the shmget() issue (which seems impervious to setuidness).
When I add it back, the adjtimex() issue returns.
There is a red herring in my strace output - my output of
"
On 23/08/2012 11:54, Tomalak Geret'kal wrote:
So that's (sort of) one mystery solved. I'll have to
investigate as to where that setuid bit is getting set.
Found it - chmod 4755 was erroneously applied in some cases
on installation due to a permissions & sudo confusion. It
On 23/08/2012 11:47, Miroslav Lichvar wrote:
On Thu, Aug 23, 2012 at 11:04:05AM +0100, Tomalak Geret'kal wrote:
It seems odd that chrony fails to open /var/run/chrony.pid and fails
to adjtimex(), presumably both through permissions errors (though
this is only made clear-ish for the l
On 21/08/2012 20:33, Miroslav Lichvar wrote:
On Tue, Aug 21, 2012 at 06:05:46PM +0100, Tomalak Geret'kal wrote:
It's really just the adjtimex()/shmget() oddity I'm confused about
now. It really does seem to occur largely randomly and then vanish
when I replace the binary with a
On 21/08/2012 20:33, Miroslav Lichvar wrote:
On Tue, Aug 21, 2012 at 06:05:46PM +0100, Tomalak Geret'kal wrote:
I don't experience this issue at all when "noselect" is used on the
NMEA/"GPS" source. That is, when I can launch chronyd past my
adjtimex()/shmget() iss
On 21/08/2012 22:58, Bill Unruh wrote:
I'm afraid I may not have made clear the context of the
above `chronyc sources` output, which was only to
demonstrate what happens after a while when I don't have
"noselect" on the GPS source and the GPS source has been
selected by chrony after a "no majo
On 21/08/2012 19:35, Bill Unruh wrote:
On Tue, 21 Aug 2012, Tomalak Geret'kal wrote:
On 21/08/2012 16:31, Bill Unruh wrote:
> > The SHM is fed by a known-good process that works
with ntpd and also > here
Is it a secret which program you use?
No, it's not a secret, b
On 21/08/2012 16:31, Bill Unruh wrote:
On Mon, 20 Aug 2012, Tomalak Geret'kal wrote:
On 20/08/2012 22:44, Bill Unruh wrote:
Hmm. How are you feeding the shm? The PPS source cannot
give you the
seconds.
It is only accurate to the nsec, but completely
oblivious to seconds, so
you
On 21/08/2012 10:24, Miroslav Lichvar wrote:
There are some other areas which needs update, for
instance the section with server name resolving on start
is no longer valid, as chrony will try it later after start.
That's interesting actually as when I put NTP servers "ntp1"
"ntp2" "ntp3" (whic
On 20/08/2012 22:44, Bill Unruh wrote:
On Mon, 20 Aug 2012, Tomalak Geret'kal wrote:
And when it *does* start up successfully, I find that
after some time (this varies, but on last observation was
around ten minutes after startup) my GPS source is being
selected over my PPS source (af
On 20/08/2012 22:29, Tomalak Geret'kal wrote:
And when it *does* start up successfully, I find that
after some time (this varies, but on last observation was
around ten minutes after startup) my GPS source is being
selected over my PPS source (after a "no majority" event),
and
On 20/08/2012 21:58, Bill Unruh wrote:
Sorry cannot say, but there is a manual adjtimex program
under linux
( man 8 adjtimex)
which you could try running and see if you get some error
messages.
Also the system call adjtimex sets errno, and you should
be able to get more
info out of it. I can
On 20/08/2012 18:49, Tomalak Geret'kal wrote:
Hi
I'm replacing ntpd with chronyd on a busybox-driven Linux
2.6.21 ARM device that takes time from a local GPS
receiver with PPS and/or remote NTP servers. We've never
been able to get ntpd working with the ATOM PPS driver an
Hi
I'm replacing ntpd with chronyd on a busybox-driven Linux
2.6.21 ARM device that takes time from a local GPS receiver
with PPS and/or remote NTP servers. We've never been able to
get ntpd working with the ATOM PPS driver and we have some
fiddly time-step requirements that led us to decide
49 matches
Mail list logo
