Hal Murray :
>
> e...@thyrsus.com said:
> >> Perhaps we should review this area. What will we want to see
> >> when NTS is deployed.
> > You and Achim are probably the best judges of that we have. So write a
> > strawman and put it in nts.adoc.
>
> I don't plan to put anything related to this
Hal Murray via devel :
> ntp_control really needs a big cleanup. There are several tables that must
> be
> kept in sync by hand. I added issue #539 for that. (It may be a duplicate,
> but I didn't see an old one.)
I noticed that back when I was in "rip out all the code" mode.
Priority: ba
Achim Gratz via devel :
> Well, it turns out ntpq has regressed from classic and doesn't
> understand at least some of that syntax anymore:
>
> Classic> /usr/sbin/ntpq -c 'rv 0 offset'
> offset=-0.023122
>
> NTPsec~> ntpq -c 'rv 0 offset'
> server=0 status=0415 leap_none, sync_uhf_radio, 1 event,
e...@thyrsus.com said:
>> Perhaps we should review this area. What will we want to see
>> when NTS is deployed.
> You and Achim are probably the best judges of that we have. So write a
> strawman and put it in nts.adoc.
I don't plan to put anything related to this into nts.adoc
ntp_control
> So, lockclock is not known as a system variable of course.
I just pushed a fix for that.
$ ntpq
ntpq> rv 0 lockclock
lockclock=0
ntpq>
ntp_control really needs a big cleanup. There are several tables that must be
kept in sync by hand. I added issue #539 for that. (It may be a
io, 1 event, clock_sync,
>> version="ntpd ntpsec-1.1.3+ 2019-01-21T16:51:20Z (git rev 6c029ef4c)",
> ...
>
> Works for me. Anything interesting about your setup?
No, just plain stupidity on my side. I tried to run the command via ssh
and forgot I need to double-quote
Achim said:
> Well, it turns out ntpq has regressed from classic and doesn't understand at
> least some of that syntax anymore:
> NTPsec~> ntpq -c 'rv 0 offset'
> server=0 status=0415 leap_none, sync_uhf_radio, 1 event, clock_sync,
> version="ntpd ntpsec-1.1.3+ 2019-01-21T16:51:20Z (git rev 6c0
Hal Murray via devel writes:
> It's easy to add new variables. Old ntpq may not show them in any of its
> packaged printout like peers or kerninfo, but you can get them by asking
> explicityly.
Well, it turns out ntpq has regressed from classic and doesn't
understand at least some of that synta
Eric S. Raymond via devel writes:
> Achim Gratz via devel :
>> It would be nice if lockclock mode would get displayed in the system
>> variables in ntpq if it was on, however.
>
> Alas, it's not a system variable.
>
> I could, I suppose, make it one. But you can
Hal Murray :
> Perhaps we should review this area. What will we want to see when NTS is
> deployed.
You and Achim are probably the best judges of that we have. So write a strawman
and put it in nts.adoc.
--
http://www.catb.org/~esr/";>Eric S. Raymond
My work is funded by the I
Eric said:
> It's never been an an *ntpq* "system variable" that can be queried through
> that interface, I meant.
It's easy to add new variables. Old ntpq may not show them in any of its
packaged printout like peers or kerninfo, but you can get them by asking
explicityly.
There are also 2
Hal Murray :
> > Alas, it's not a system variable.
>
> Looks like it is:
> include/ntpd.h:extern bool lockclock; /* lock to the system
> clock? */
It's never been an an *ntpq* "system variable" that can be queried through
that interf
> Alas, it's not a system variable.
Looks like it is:
include/ntpd.h:extern bool lockclock; /* lock to the system
clock? */
--
These are my opinions. I hate spam.
___
devel mailing list
devel@ntpsec.org
http://lists.nt
Achim Gratz via devel :
> It would be nice if lockclock mode would get displayed in the system
> variables in ntpq if it was on, however.
Alas, it's not a system variable.
I could, I suppose, make it one. But you can get the same effect by querying the
driver tyo
or me.
It would be nice if lockclock mode would get displayed in the system
variables in ntpq if it was on, however.
Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
SD adaptations for KORG EX-800 and Poly-800MkII V0.9:
http://Synth.Stromeko.net
Richard Laager :
> On 1/21/19 2:28 PM, Eric S. Raymond via devel wrote:
> > I don't either, and I think there is no functional point in trying to cope
> > with that. So I'm going to deal with this by adding to the documentation a
> > line that says changing this flag at runtime may produce undefine
On 1/21/19 2:28 PM, Eric S. Raymond via devel wrote:
> I don't either, and I think there is no functional point in trying to cope
> with that. So I'm going to deal with this by adding to the documentation a
> line that says changing this flag at runtime may produce undefined behavior.
Is it easy t
yself
> that all the initializations are going to happen correctly when
> lockclock is switched on and off, I really don't see how I'd go about
> that.
I don't either, and I think there is no functional point in trying to cope
with that. So I'm going to deal with t
that patch.
In principle you can mobilize/demobilize associations and change their
flags at runtime (I haven't done that in a while so I don't know if it
still works the same as in classic). So if I need to convince myself
that all the initializations are going to happen correctly when
lockcl
Richard Laager via devel :
> docs/driver_local.adoc has a typo: disctplined
Fixed, thanks.
--
http://www.catb.org/~esr/";>Eric S. Raymond
My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save
docs/driver_local.adoc has a typo: disctplined
--
Richard
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
I have converted ENABLE_LOCKCLOCK to a runtime option. Following a
review suggestion, it is controlled by flag1 of the localclock driver.
Please test carefully. I think I avoided breaking the loopfilter
code, but there;s always that outside chance...
--
http://www.catb.org/~esr/"
- I generally push directly.
> If not...
>
> +* NIST lockclock mode is now a tinker flag rather than a compile-time
> + option, heading off bad things that can occur if a distro packager
> + gets careless and enables every compile-time option by default.
>
> ^ "g
Hal Murray via devel writes:
>> The easiest is probably to configure the GPS refclock into a private ntpd
>> instance running on a hidden port. Another exposed ntpd then runs in
>> lockclock mode and serves the system time controlled by the hidden instance.
>
> That
On 1/12/19 8:10 AM, Eric S. Raymond via devel wrote:
> Please review and test.
Can you please post this as a merge request, so we can use GitLab
comment/review/approval processes and automated testing?
If not...
+* NIST lockclock mode is now a tinker flag rather than a compile-time
+ opt
447cc231e9b Mon Sep 17 00:00:00 2001
From: "Eric S. Raymond"
Date: Sat, 12 Jan 2019 09:04:16 -0500
Subject: [PATCH] Change NIST lockclock enable from a compile-time option to a
tinker flag.
Heads off a problem with distro packagers carelessly enabling all compile-time
options. Thi
Hal Murray :
>
> >> If we are serious about supporting lockclock, we have to figure out a way
> to
> >> test it. We can probably make something that supports GPSDOs with PPS.
>
> > That, on the other hand, seems to me like a good idea. But I don't
Hal Murray :
>
> e...@thyrsus.com said:
> > Not only is it possible, I wrote a patch to do it today. Complete with
> > documentation changes. I'll post it shortly - I want it carefully reviewed
> > and tested by others before we merge it, as it touched the loppfilter code.
>
> Are you planning
> The easiest is probably to configure the GPS refclock into a private ntpd
> instance running on a hidden port. Another exposed ntpd then runs in
> lockclock mode and serves the system time controlled by the hidden instance.
That's a good straw man. Thanks. If I understa
e...@thyrsus.com said:
> Not only is it possible, I wrote a patch to do it today. Complete with
> documentation changes. I'll post it shortly - I want it carefully reviewed
> and tested by others before we merge it, as it touched the loppfilter code.
Are you planning to push it before or afte
>> If we are serious about supporting lockclock, we have to figure out a way
to
>> test it. We can probably make something that supports GPSDOs with PPS.
> That, on the other hand, seems to me like a good idea. But I don't have the
> domain expertise to do it.
Ind
Hal Murray via devel :
>
> devel@ntpsec.org said:
> > Is it possible to make lockclock a run-time-only option, instead of a
> > compile-time + runtime otion?
>
> I think so. That will require adding something to ntp.conf to turn it on.
Not only is it possible, I wrot
devel@ntpsec.org said:
> Is it possible to make lockclock a run-time-only option, instead of a
> compile-time + runtime otion?
I think so. That will require adding something to ntp.conf to turn it on.
> If remains a compile-time option, then we'll need to add CI targets for it s
Gary E. Miller via devel :
> Yo Matthew!
>
> On Fri, 11 Jan 2019 17:44:42 +
> Matthew Selsky via devel wrote:
>
> > Is it possible to make lockclock a run-time-only option, instead of a
> > compile-time + runtime otion?
>
> I'd love to get rid of ev
Yo Matthew!
On Fri, 11 Jan 2019 17:44:42 +
Matthew Selsky via devel wrote:
> Is it possible to make lockclock a run-time-only option, instead of a
> compile-time + runtime otion?
I'd love to get rid of every compile time option. They confuse
distro maintainers, which leads to
Is it possible to make lockclock a run-time-only option, instead of a
compile-time + runtime otion?
If remains a compile-time option, then we'll need to add CI targets for it so
that we're always testing that it compiles cleanly.
Tha
nt
> > NIST was running NTP Classic on the master fountain clock. For all we know
> > they might still be doing that.
>
> I expect the lockclock code is a partnership between Dave Mills and Judah
> Levine at NIST.
I didn't have a name at the NIST end but, yeah, I was
Hal Murray via devel writes:
> If we are serious about supporting lockclock, we have to figure out a way to
> test it. We can probably make something that supports GPSDOs with PPS.
The easiest is probably to configure the GPS refclock into a private
ntpd instance running on a hidde
n the master fountain clock. For all we know
> they might still be doing that.
I expect the lockclock code is a partnership between Dave Mills and Judah
Levine at NIST.
> This is an NTPsec use case we *absolutely* want to encourage. What better
> reference user could we have?
> So, y
Gary said:
> Lockclock mode is very important to the PTP people. They use PTP to
> distribute time on the local net to the clients. Then a PTP client can use
> NTP to server time to not PTP clients.
Thanks. Is there any sort of documentation (email?) or a HOWTO?
Do they actually
> lockclock stays in
OK
You need to think about what "stays in" means. Do you want to support it? If
so, we need documentation and a test case.
I will let somebody else take care of Issue #524
The simplest fix that I can think of is to change --enable-lockclock to
something
lockclock stays in
Thanks!
..m
On Sun, Jan 6, 2019 at 6:28 AM Eric S. Raymond via devel
wrote:
> Gary E. Miller via devel :
> > Lockclock mode is very important to the PTP people. They use PTP to
> > distribute time on the local net to the clients. Then a PTP client can
Gary E. Miller via devel :
> Lockclock mode is very important to the PTP people. They use PTP to
> distribute time on the local net to the clients. Then a PTP client can
> use NTP to server time to not PTP clients.
While I have no doubt you are correct about the PTP deployment, I see
Eric S. Raymond via devel writes:
> It's because the only way this code makes any sense to me is if at one
> point NIST was running NTP Classic on the master fountain clock. For all
> we know they might still be doing that.
…the other (and more practical one) is if your system clock is
disciplined
Hal Murray via devel :
>
> Context is Issue #524, NTPsec daemon hangs after startup
>
> The problem is that if configured with --enable-lockclock, ntpd doesn't work
> as a server if you don't activate the local clock driver in your ntp.conf.
> (It doe
Yo Hal!
On Fri, 04 Jan 2019 23:13:39 -0800
Hal Murray via devel wrote:
> I vote for dropping it. We can put things back together if we find a
> customer who wants it.
Lockclock mode is very important to the PTP people. They use PTP to
distribute time on the local net to the clients.
Context is Issue #524, NTPsec daemon hangs after startup
The problem is that if configured with --enable-lockclock, ntpd doesn't work
as a server if you don't activate the local clock driver in your ntp.conf.
(It doesn't work as a client either.)
---
Ther
47 matches
Mail list logo
