On 2015-02-25, Paul wrote:
> On Tue, Feb 24, 2015 at 4:17 PM, William Unruh wrote:
>
>> It is superior in that you can do it easily. Whether that is of any
>> importance to you is of course up to you. Myself I have never used it.
>>
>
> As is often the case you completely miss the point.
As is o
On 2015-02-25, Paul wrote:
> On Tue, Feb 24, 2015 at 3:22 PM, Charles Swiger wrote:
>
>>
>> Data is available. Feel free to review the papers referenced from:
>>
>
> I was unclear. I mean specific research regarding disciplining a clock via
> manual correction not human coordination or fine mot
On Tue, Feb 24, 2015 at 4:17 PM, William Unruh wrote:
> It is superior in that you can do it easily. Whether that is of any
> importance to you is of course up to you. Myself I have never used it.
>
As is often the case you completely miss the point.
> Fine. It has already been written for chr
On Tue, Feb 24, 2015 at 3:22 PM, Charles Swiger wrote:
>
> Data is available. Feel free to review the papers referenced from:
>
I was unclear. I mean specific research regarding disciplining a clock via
manual correction not human coordination or fine motor control.
As I said, an unbiased ass
On 2015-02-24, Paul wrote:
> On Tue, Feb 24, 2015 at 1:14 PM, Charles Swiger wrote:
>
>> On Feb 23, 2015, at 11:57 PM, David Woolley
>> wrote:
>> > On 23/02/15 21:23, William Unruh wrote:
>> >> manual corrections are probably good to 1 sec.
>> >
>> > It's a long time since I did this, but 200ms
On Feb 24, 2015, at 11:40 AM, Paul wrote:
>> However, if you time things with a rhythm you can get to ~50 ms or better
>
> While these performance anecdotes are interesting they (starting with
> unruh@invalid) are all anecdotes. I didn't mention research and real
> numbers by accident.
Data is
On Tue, Feb 24, 2015 at 1:14 PM, Charles Swiger wrote:
> On Feb 23, 2015, at 11:57 PM, David Woolley
> wrote:
> > On 23/02/15 21:23, William Unruh wrote:
> >> manual corrections are probably good to 1 sec.
> >
> > It's a long time since I did this, but 200ms is more like it
>
> However, if you t
Charles Swiger wrote:
On Feb 23, 2015, at 11:57 PM, David Woolley
wrote:
On 23/02/15 21:23, William Unruh wrote:
manual corrections are probably good to 1 sec. to get 1 sec at 2ppm is
about 5 days per measurement or 10 days altogether.
It's a long time since I did this, but 200ms is more li
On Feb 23, 2015, at 11:57 PM, David Woolley
wrote:
> On 23/02/15 21:23, William Unruh wrote:
>> manual corrections are probably good to 1 sec. to get 1 sec at 2ppm is
>> about 5 days per measurement or 10 days altogether.
>
> It's a long time since I did this, but 200ms is more like it (might ha
On 23/02/15 21:23, William Unruh wrote:
manual corrections are probably good to 1 sec. to get 1 sec at 2ppm is
about 5 days per measurement or 10 days altogether.
It's a long time since I did this, but 200ms is more like it (might have
been 100ms). You need digital clock that is, itself, sy
On 2015-02-23, Harlan Stenn wrote:
> William Unruh writes:
>> On 2015-02-23, Harlan Stenn wrote:
>> > Miroslav Lichvar writes:
>> >> On Sat, Feb 21, 2015 at 07:02:28PM +, David Taylor wrote:
>> >> > On 21/02/2015 17:52, William Unruh wrote:
>> >> > []
>> >> > >It will do that too. The crucial
On 2015-02-23, Paul wrote:
> On Mon, Feb 23, 2015 at 12:53 PM, William Unruh wrote:
>
>> As Lichvar says with chrony
>> you periodically read your watch, or listen to radio, and set the time
>> and chrony figures out that you have a drift rate of about 30PPM and
>> corrects. Now you may not value
On Mon, Feb 23, 2015 at 12:53 PM, William Unruh wrote:
> As Lichvar says with chrony
> you periodically read your watch, or listen to radio, and set the time
> and chrony figures out that you have a drift rate of about 30PPM and
> corrects. Now you may not value that possibility, which is perfect
On 2015-02-23, Harlan Stenn wrote:
> Miroslav Lichvar writes:
>> On Sat, Feb 21, 2015 at 07:02:28PM +, David Taylor wrote:
>> > On 21/02/2015 17:52, William Unruh wrote:
>> > []
>> > >It will do that too. The crucial item there is "the only method of time
>> > >correction is manual entry" whic
Miroslav Lichvar writes:
> On Sat, Feb 21, 2015 at 07:02:28PM +, David Taylor wrote:
> > On 21/02/2015 17:52, William Unruh wrote:
> > []
> > >It will do that too. The crucial item there is "the only method of time
> > >correction is manual entry" which is different from ntpd and orphan
> > >mo
On Sat, Feb 21, 2015 at 07:02:28PM +, David Taylor wrote:
> On 21/02/2015 17:52, William Unruh wrote:
> []
> >It will do that too. The crucial item there is "the only method of time
> >correction is manual entry" which is different from ntpd and orphan
> >mode. I have no idea why this conversat
On 2015-02-21, Paul wrote:
> On Sat, Feb 21, 2015 at 1:57 AM, William Unruh wrote:
>>
>> On 2015-02-21, Paul wrote:
>> > On Fri, Feb 20, 2015 at 3:23 PM, William Unruh wrote:
>> >
>> >> ??? how do assume that the chrony docs do not tell the truth?
>> ^ you
>>
>
> Okay, I'll assume
On Sat, Feb 21, 2015 at 1:57 AM, William Unruh wrote:
>
> On 2015-02-21, Paul wrote:
> > On Fri, Feb 20, 2015 at 3:23 PM, William Unruh wrote:
> >
> >> ??? how do assume that the chrony docs do not tell the truth?
> ^ you
>
Okay, I'll assume (or pretend) that you mean "Why do I ass
On 21/02/2015 17:52, William Unruh wrote:
[]
It will do that too. The crucial item there is "the only method of time
correction is manual entry" which is different from ntpd and orphan
mode. I have no idea why this conversation is continuing. The two are
different. The two methods are trying to s
William Unruh wrote:
> What are you using? Are you on ntpd or chrony?
Please do not followup to my postings when you don't care to follow
the thread!
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
On 2015-02-21, Rob wrote:
> William Unruh wrote:
>> On 2015-02-19, Rob wrote:
>>> Miroslav Lichvar wrote:
On Thu, Feb 19, 2015 at 12:48:46PM +, Rob wrote:
> I am still finding out what sensor is best to use, we do have a room
> temperature sensor that has .1C resolution and is
On 2015-02-21, Rob wrote:
> William Unruh wrote:
>> On 2015-02-19, Rob wrote:
>>> Miroslav Lichvar wrote:
On Thu, Feb 19, 2015 at 10:05:45AM +, Rob wrote:
> We have systems in places that are not temperature controlled and then
> chrony is much better. I am looking for the bes
Brian Inglis wrote:
> On 2015-02-21 01:00, Rob wrote:
>> William Unruh wrote:
>>> On 2015-02-19, Rob wrote:
Miroslav Lichvar wrote:
> On Thu, Feb 19, 2015 at 10:05:45AM +, Rob wrote:
>> We have systems in places that are not temperature controlled and then
>> chrony is much
On 2015-02-21, David Taylor wrote:
> On 21/02/2015 07:04, William Unruh wrote:
> []
>> orphan mode is about a group of computers. "Orphan Mode allows a group
>> of ntpd processes to automonously select a leader in the event that all
>> real time sources become unreachable (i.e. are inaccessible)."
On 2015-02-21 01:00, Rob wrote:
William Unruh wrote:
On 2015-02-19, Rob wrote:
Miroslav Lichvar wrote:
On Thu, Feb 19, 2015 at 10:05:45AM +, Rob wrote:
We have systems in places that are not temperature controlled and then
chrony is much better. I am looking for the best way to find t
David Taylor wrote:
On 21/02/2015 07:04, William Unruh wrote:
[]
orphan mode is about a group of computers. "Orphan Mode allows a group
of ntpd processes to automonously select a leader in the event that all
real time sources become unreachable (i.e. are inaccessible)."
chrony's is that you can
William Unruh wrote:
> On 2015-02-19, Rob wrote:
>> Miroslav Lichvar wrote:
>>> On Thu, Feb 19, 2015 at 10:05:45AM +, Rob wrote:
We have systems in places that are not temperature controlled and then
chrony is much better. I am looking for the best way to find the
values to u
David Taylor writes:
> On 21/02/2015 07:04, William Unruh wrote:
> []
> > orphan mode is about a group of computers. "Orphan Mode allows a group
> > of ntpd processes to automonously select a leader in the event that all
> > real time sources become unreachable (i.e. are inaccessible)."
> >
> > chr
William Unruh wrote:
> On 2015-02-19, Rob wrote:
>> Miroslav Lichvar wrote:
>>> On Thu, Feb 19, 2015 at 12:48:46PM +, Rob wrote:
I am still finding out what sensor is best to use, we do have a room
temperature sensor that has .1C resolution and is readable via snmp,
and there
On 21/02/2015 07:04, William Unruh wrote:
[]
orphan mode is about a group of computers. "Orphan Mode allows a group
of ntpd processes to automonously select a leader in the event that all
real time sources become unreachable (i.e. are inaccessible)."
chrony's is that you can enter the time by ha
On 2015-02-21, Paul wrote:
> On Fri, Feb 20, 2015 at 3:23 PM, William Unruh wrote:
>
>> ??? how do assume that the chrony docs do not tell the truth?
^ you
>
>
> I don't understand that sentence.
___
questions mailing list
questions@lists
On 2015-02-21, David Taylor wrote:
> On 20/02/2015 20:22, William Unruh wrote:
> []
>> No. The local clock simply trusts the time (Ie all offsets are defined
>> to be zero) chrony takes the time as entered by hand by the operator and
>> uses that to determine the offset. Of course that will not be
On 20/02/2015 20:22, William Unruh wrote:
[]
No. The local clock simply trusts the time (Ie all offsets are defined
to be zero) chrony takes the time as entered by hand by the operator and
uses that to determine the offset. Of course that will not be terribly
accurate ( a second is probably good)
On Fri, Feb 20, 2015 at 3:23 PM, William Unruh wrote:
> ??? how do assume that the chrony docs do not tell the truth?
I don't understand that sentence.
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
On 2015-02-19, Paul wrote:
> On Thu, Feb 19, 2015 at 5:34 AM, David Taylor <
> david-tay...@blueyonder.co.uk.invalid> wrote:
>
>> Does not NTP's orphan mode and local clock driver provide this?
>
>
> Refclock 1 (LOCAL/LOCL) is deprecated and I believe as of a recent release
> it's useless* but "Or
On 2015-02-19, Rob wrote:
> Miroslav Lichvar wrote:
>> My update to that after the years would be that 3x is not really the
>> minimum difference. If the clock is stable enough, they can perform
>> similarly.
>
> Indeed when a system is in a reasonably constant temperature and the
> clock happens
On 2015-02-19, David Taylor wrote:
> On 19/02/2015 01:24, Paul wrote:
> []
>> Chrony (in general) pros and cons: <
>> http://chrony.tuxfamily.org/manual.html#Other-time-synchronisation-packages>
> []
>
> ... whwre it says: "Things chronyd can do that ntpd can?t: chronyd
> provides support for is
On 2015-02-19, Rob wrote:
> Miroslav Lichvar wrote:
>> On Thu, Feb 19, 2015 at 10:05:45AM +, Rob wrote:
>>> We have systems in places that are not temperature controlled and then
>>> chrony is much better. I am looking for the best way to find the
>>> values to use in the tempcomp configurat
On 2015-02-19, Rob wrote:
> Miroslav Lichvar wrote:
>> On Thu, Feb 19, 2015 at 12:48:46PM +, Rob wrote:
>>> I am still finding out what sensor is best to use, we do have a room
>>> temperature sensor that has .1C resolution and is readable via snmp,
>>> and there are the usual sensors for boa
On Thu, Feb 19, 2015 at 10:58:14PM +, Harlan Stenn wrote:
> Would the temperature monitoring script and coefficient
> generation/processsing stuff be a good GSoC project?
Not really, it would be probably easier to write the scripts than
write the GSoC application.
I'd be more interested in so
On Thu, Feb 19, 2015 at 04:15:45PM +, Rob wrote:
> > The default PPS refclock driver poll is 0 (1s), this be changed too
> > if the PPS signal has a higher rate. Some GPS units seems to have this
> > configurable (e.g. ublox NEO-6T).
>
> The PPS really is 1 PPS, but I am not sure if chrony is
On Thu, Feb 19, 2015 at 6:16 PM, Harlan Stenn wrote:
> While that document is old and unmaintained
>
So put an appropriate note at the top of it and on the link to it from the
WebHome page. No one that stumbles onto it is going to find any "gems".
___
Paul writes:
> On Thu, Feb 19, 2015 at 12:35 PM, David Taylor <
> david-tay...@blueyonder.co.uk.invalid> wrote:
>
> > Accurate and current documentation is both essential and invaluable for
> > any project!
>
> Well then under no circumstances should you read the ntp faq/howto at <
> http://www.n
Would the temperature monitoring script and coefficient
generation/processsing stuff be a good GSoC project?
If so, if somebody wants to mentor this please add it as an idea at
http://support.ntp.org/bin/view/Dev/GSoCProjectIdeas
H
___
questions mailing
On 19/02/2015 18:09, Paul wrote:
On Thu, Feb 19, 2015 at 12:35 PM, David Taylor <
david-tay...@blueyonder.co.uk.invalid> wrote:
Accurate and current documentation is both essential and invaluable for
any project!
Well then under no circumstances should you read the ntp faq/howto at <
http://
I admit that I have not looked at the chrony code/doc and do not use it as it
when I did take a look, it had no ref clock support so I don’t know what the
objective is here. That said, from the current discussion I have a feeling that
integrating temperature data into the clock control loop is n
On Thu, Feb 19, 2015 at 12:35 PM, David Taylor <
david-tay...@blueyonder.co.uk.invalid> wrote:
> Accurate and current documentation is both essential and invaluable for
> any project!
Well then under no circumstances should you read the ntp faq/howto at <
http://www.ntp.org/ntpfaq/NTP-a-faq.htm>
On 19/02/2015 14:20, Paul wrote:
On Thu, Feb 19, 2015 at 5:34 AM, David Taylor <
david-tay...@blueyonder.co.uk.invalid> wrote:
Does not NTP's orphan mode and local clock driver provide this?
Refclock 1 (LOCAL/LOCL) is deprecated and I believe as of a recent release
it's useless* but "Orphan
Miroslav Lichvar wrote:
> On Thu, Feb 19, 2015 at 02:42:39PM +, Rob wrote:
>> Ok but of course we are using PPS and a 16 second polling interval.
>> (or maybe the PPS refclock polls even faster although it displays 4 as
>> the poll interval indicator)
>
> You may want to try a shorter polling
On Thu, Feb 19, 2015 at 9:42 AM, Rob wrote:
>
> Ok but of course we are using PPS and a 16 second polling interval.
>
Use eight unless your system is broken in which replace it and then use
eight.
___
questions mailing list
questions@lists.ntp.org
http
On Thu, Feb 19, 2015 at 02:42:39PM +, Rob wrote:
> Ok but of course we are using PPS and a 16 second polling interval.
> (or maybe the PPS refclock polls even faster although it displays 4 as
> the poll interval indicator)
You may want to try a shorter polling interval and see if the swings
ar
Miroslav Lichvar wrote:
> On Thu, Feb 19, 2015 at 12:48:46PM +, Rob wrote:
>> I am still finding out what sensor is best to use, we do have a room
>> temperature sensor that has .1C resolution and is readable via snmp,
>> and there are the usual sensors for board- and inlet air temperature.
>>
On Thu, Feb 19, 2015 at 5:34 AM, David Taylor <
david-tay...@blueyonder.co.uk.invalid> wrote:
> Does not NTP's orphan mode and local clock driver provide this?
Refclock 1 (LOCAL/LOCL) is deprecated and I believe as of a recent release
it's useless* but "Orphan mode is intended to replace the loc
On Thu, Feb 19, 2015 at 12:48:46PM +, Rob wrote:
> I am still finding out what sensor is best to use, we do have a room
> temperature sensor that has .1C resolution and is readable via snmp,
> and there are the usual sensors for board- and inlet air temperature.
> (and of course CPU temperature
Miroslav Lichvar wrote:
> On Thu, Feb 19, 2015 at 10:05:45AM +, Rob wrote:
>> We have systems in places that are not temperature controlled and then
>> chrony is much better. I am looking for the best way to find the
>> values to use in the tempcomp configuration directive.
>
> What resolutio
On Thu, Feb 19, 2015 at 10:05:45AM +, Rob wrote:
> We have systems in places that are not temperature controlled and then
> chrony is much better. I am looking for the best way to find the
> values to use in the tempcomp configuration directive.
What resolution does the sensor have? Don't exp
On 19/02/2015 01:24, Paul wrote:
[]
Chrony (in general) pros and cons: <
http://chrony.tuxfamily.org/manual.html#Other-time-synchronisation-packages>
[]
... whwre it says: "Things chronyd can do that ntpd can’t: chronyd
provides support for isolated networks whether the only method of time
c
Miroslav Lichvar wrote:
> My update to that after the years would be that 3x is not really the
> minimum difference. If the clock is stable enough, they can perform
> similarly.
Indeed when a system is in a reasonably constant temperature and the
clock happens to be good, ntpd performs similar to
On Wed, Feb 18, 2015 at 10:00:08PM -0500, Paul wrote:
> On Wed, Feb 18, 2015 at 8:53 PM, William Unruh wrote:
> > On 2015-02-19, Paul wrote:
> > > In the specific case of PPS I don't see any advantage.
> >
> > Well, no. Lichvar did some tests with PPS and found that chrony
> > disciplined the clo
William Unruh wrote:
>> In the specific case of PPS I don't see any advantage.
>
> Well, no. Lichvar did some tests with PPS and found that chrony
> disciplined the clock much better than did ntpd (factors of over 10). I
> think that is a difference.
I am seeing the same thing on our PPS synchro
On Wed, Feb 18, 2015 at 8:53 PM, William Unruh wrote:
> On 2015-02-19, Paul wrote:
> > On Wed, Feb 18, 2015 at 6:49 AM, Charles Elliott >
> > wrote:
> >
> >> If you don't mind me asking, why is chrony superior to NTPD
> >> for tracking a PPS signal, or even in general
> >
> >
> > Chrony (in gen
On 2015-02-19, Paul wrote:
> On Wed, Feb 18, 2015 at 6:49 AM, Charles Elliott
> wrote:
>
>> If you don't mind me asking, why is chrony superior to NTPD
>> for tracking a PPS signal, or even in general
>
>
> Chrony (in general) pros and cons: <
> http://chrony.tuxfamily.org/manual.html#Other-time-
On Wed, Feb 18, 2015 at 6:49 AM, Charles Elliott
wrote:
> If you don't mind me asking, why is chrony superior to NTPD
> for tracking a PPS signal, or even in general
Chrony (in general) pros and cons: <
http://chrony.tuxfamily.org/manual.html#Other-time-synchronisation-packages>
In the specif
On
> Behalf Of Rob
> Sent: Tuesday, February 17, 2015 3:27 AM
> To: questions@lists.ntp.org
> Subject: Re: [ntp:questions] chrony as a server
>
> David Woolley wrote:
> > On 15/02/15 22:40, Rob wrote:
> >> it is tracking very ni
On 2015-02-17, Rob wrote:
> William Unruh wrote:
>> As I said I have six machines, one of which is at home over an cable
>> modem line, all getting their time from chrony on a server. No trouble
>> whatsoever, and I have never had any. This suggests that there is
>> something else going on. Now,
William Unruh wrote:
> As I said I have six machines, one of which is at home over an cable
> modem line, all getting their time from chrony on a server. No trouble
> whatsoever, and I have never had any. This suggests that there is
> something else going on. Now, I do not have the very latest chr
On 16/02/2015 19:54, Paul wrote:
On Mon, Feb 16, 2015 at 2:57 AM, David Taylor <
david-tay...@blueyonder.co.uk.invalid> wrote:
For me, there are two show-stoppers with Chrony:
- no support for standard NTP monitoring commands.
- no support for ref-clocks on Windows.
Like many others, I have
On 2015-02-16, Rob wrote:
> William Unruh wrote:
>> On 2015-02-15, Rob wrote:
>>> I am experimenting with chrony 1.31 as an alternative on some PPS
>>> synchronized servers. It appears to run OK, it is tracking very nicely:
>>>
>>> Reference ID: 80.80.83.48 (PPS0)
>>> Stratum : 1
>
On Mon, Feb 16, 2015 at 07:19:39PM +, Rob wrote:
> The PPS refclock has changed is refid from PPP0 to PPP1 with this version.
That is a bug, the refid numbering wasn't supposted to change in the
new version. Fixed in git. Thanks.
--
Miroslav Lichvar
__
David Woolley wrote:
> On 15/02/15 22:40, Rob wrote:
>> it is tracking very nicely
>
> Tracking what?
The PPS signal.
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
Miroslav Lichvar wrote:
On Mon, Feb 16, 2015 at 03:51:07PM +, David Lord wrote:
Miroslav Lichvar wrote:
As a workaround you can add "acquisitionport 123" to chrony.conf to
use just one socket for all (client, peer, server) communication,
which will effectively disable the check in which the
On 15/02/15 22:40, Rob wrote:
it is tracking very nicely
Tracking what?
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
On Mon, Feb 16, 2015 at 12:14 PM, David Taylor <
david-tay...@blueyonder.co.uk.invalid> wrote:
> I have a non-trivial interest
I meant in Ntimed (the system) not time transfer in general.
> If ntimed is not going to be available for Windows and OS/X that rules it
> out for the great majority o
On Mon, Feb 16, 2015 at 2:57 AM, David Taylor <
david-tay...@blueyonder.co.uk.invalid> wrote:
> For me, there are two show-stoppers with Chrony:
>
> - no support for standard NTP monitoring commands.
>
> - no support for ref-clocks on Windows.
>
> Like many others, I have built up a considerable m
Miroslav Lichvar wrote:
> On Mon, Feb 16, 2015 at 03:30:52PM +, Rob wrote:
>> Miroslav Lichvar wrote:
>> > On Mon, Feb 16, 2015 at 02:00:30PM +, Rob wrote:
>> >> Is chronyc of 1.31 compatible with chronyd 2.0?
>> >
>> > Yes, old configuration should still work. But you can use
>> > "acqui
On Mon, Feb 16, 2015 at 03:12:27PM +0100, Terje Mathisen wrote:
> William Unruh wrote:
> >I think, but am not sure, that the biggest problem with porting chrony
> >to windows is that windows does not have a good way of having the kernel
> >discipline the clock-- the equivalent of adjtimex on Linux.
On 16/02/2015 15:59, Paul wrote:
[]
If you have a non-trivial interest I suggest reading the notes. E.g.
"Ntimed-client puts the entire interface to the OS timekeeping in four
trivial functions for portability, but there are other nits and downright
idiotic incompatibilities, because, quite fra
On Mon, Feb 16, 2015 at 03:51:07PM +, David Lord wrote:
> Miroslav Lichvar wrote:
> >As a workaround you can add "acquisitionport 123" to chrony.conf to
> >use just one socket for all (client, peer, server) communication,
> >which will effectively disable the check in which the server's request
On Mon, Feb 16, 2015 at 03:30:52PM +, Rob wrote:
> Miroslav Lichvar wrote:
> > On Mon, Feb 16, 2015 at 02:00:30PM +, Rob wrote:
> >> Is chronyc of 1.31 compatible with chronyd 2.0?
> >
> > Yes, old configuration should still work. But you can use
> > "acquisitionport 123" as a workaround i
Miroslav Lichvar wrote:
On Mon, Feb 16, 2015 at 12:56:27PM +, David Lord wrote:
I've just fetched chrony-2.0-pre1. It seemed to compile and
install ok on NetBSD-6/i386. The client IS one of the servers
configured in chrony.conf and it behaved same as with 1.31.
I didn't know this was such
On Mon, Feb 16, 2015 at 5:22 AM, David Taylor <
david-tay...@blueyonder.co.uk.invalid> wrote:
> I hope that ntimed will not be available only on Linux
If you have a non-trivial interest I suggest reading the notes. E.g.
"Ntimed-client puts the entire interface to the OS timekeeping in four
tri
Miroslav Lichvar wrote:
> On Mon, Feb 16, 2015 at 02:00:30PM +, Rob wrote:
>> Is chronyc of 1.31 compatible with chronyd 2.0?
>
> Yes, old configuration should still work. But you can use
> "acquisitionport 123" as a workaround if you prefer stable version.
Well I tried that before and it did
On Mon, Feb 16, 2015 at 02:00:30PM +, Rob wrote:
> Is chronyc of 1.31 compatible with chronyd 2.0?
Yes, old configuration should still work. But you can use
"acquisitionport 123" as a workaround if you prefer stable version.
--
Miroslav Lichvar
___
William Unruh wrote:
On 2015-02-16, David Taylor wrote:
On 16/02/2015 07:59, William Unruh wrote:
[]
?? There are chonyc which is its own monitoring. chrony is not ntpd, so
why would you expect ntpc monitoring commands to work?
[]
As I already said, compatibility with the installed base woul
On Mon, Feb 16, 2015 at 12:56:27PM +, David Lord wrote:
> I've just fetched chrony-2.0-pre1. It seemed to compile and
> install ok on NetBSD-6/i386. The client IS one of the servers
> configured in chrony.conf and it behaved same as with 1.31.
I didn't know this was such a common configuration
Miroslav Lichvar wrote:
> On Mon, Feb 16, 2015 at 09:59:27AM +, Rob wrote:
>> I have strace'd the daemon and I see that it does receive the datagram
>> from the socket, but it does not send a reply.
>
> Hm, interesting. Can you post what follows that recvmsg() call?
I can not do that right no
Miroslav Lichvar wrote:
> On Mon, Feb 16, 2015 at 11:29:31AM +0100, Miroslav Lichvar wrote:
>> On Mon, Feb 16, 2015 at 09:59:27AM +, Rob wrote:
>> > I have strace'd the daemon and I see that it does receive the datagram
>> > from the socket, but it does not send a reply.
>>
>> Hm, interesting
Miroslav Lichvar wrote:
On Mon, Feb 16, 2015 at 11:29:31AM +0100, Miroslav Lichvar wrote:
On Mon, Feb 16, 2015 at 09:59:27AM +, Rob wrote:
I have strace'd the daemon and I see that it does receive the datagram
from the socket, but it does not send a reply.
Hm, interesting. Can you post wha
On Mon, Feb 16, 2015 at 11:29:31AM +0100, Miroslav Lichvar wrote:
> On Mon, Feb 16, 2015 at 09:59:27AM +, Rob wrote:
> > I have strace'd the daemon and I see that it does receive the datagram
> > from the socket, but it does not send a reply.
>
> Hm, interesting. Can you post what follows that
On Mon, Feb 16, 2015 at 09:59:27AM +, Rob wrote:
> I have strace'd the daemon and I see that it does receive the datagram
> from the socket, but it does not send a reply.
Hm, interesting. Can you post what follows that recvmsg() call?
You could try running it with -d -d (after it's compiled w
On 16/02/2015 08:46, William Unruh wrote:
[]
I think, but am not sure, that the biggest problem with porting chrony
to windows is that windows does not have a good way of having the kernel
discipline the clock-- the equivalent of adjtimex on Linux.
NTP already manages that very well on Windows.
I have strace'd the daemon and I see that it does receive the datagram
from the socket, but it does not send a reply.
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
Miroslav Lichvar wrote:
> On Sun, Feb 15, 2015 at 10:40:11PM +, Rob wrote:
>> However, it does not reply to NTP requests from other systems with ntpd.
>> (I can confirm that in a network trace)
>
>> Is there a magic command that has to be in the config to make it work
>> as a server?
>
> No, y
David Lord wrote:
Rob wrote:
I am experimenting with chrony 1.31 as an alternative on some PPS
synchronized servers. It appears to run OK, it is tracking very nicely:
.
Me too, I downloaded compiled and installed earlier this
morning on NetBSD-6/i386.
When I was on dialup, I used chro
On 2015-02-16, David Taylor wrote:
> On 16/02/2015 07:59, William Unruh wrote:
> []
>> ?? There are chonyc which is its own monitoring. chrony is not ntpd, so
>> why would you expect ntpc monitoring commands to work?
> []
>
> As I already said, compatibility with the installed base would greatly
William Unruh wrote:
> On 2015-02-15, Rob wrote:
>> I am experimenting with chrony 1.31 as an alternative on some PPS
>> synchronized servers. It appears to run OK, it is tracking very nicely:
>>
>> Reference ID: 80.80.83.48 (PPS0)
>> Stratum : 1
>> Ref time (UTC) : Sun Feb 15 22:3
David Taylor wrote:
> On 15/02/2015 22:40, Rob wrote:
>> I am experimenting with chrony 1.31 as an alternative on some PPS
>> synchronized servers. It appears to run OK, it is tracking very nicely:
> []
>
> For me, there are two show-stoppers with Chrony:
>
> - no support for standard NTP monito
On Sun, Feb 15, 2015 at 10:40:11PM +, Rob wrote:
> However, it does not reply to NTP requests from other systems with ntpd.
> (I can confirm that in a network trace)
> Is there a magic command that has to be in the config to make it work
> as a server?
No, your configuration looks good. Any c
On 15/02/2015 22:40, Rob wrote:
I am experimenting with chrony 1.31 as an alternative on some PPS
synchronized servers. It appears to run OK, it is tracking very nicely:
[]
For me, there are two show-stoppers with Chrony:
- no support for standard NTP monitoring commands.
- no support for r
On 16/02/2015 07:59, William Unruh wrote:
[]
?? There are chonyc which is its own monitoring. chrony is not ntpd, so
why would you expect ntpc monitoring commands to work?
[]
As I already said, compatibility with the installed base would greatly
increase the acceptance on different software.
1 - 100 of 104 matches
Mail list logo
