e...@thyrsus.com said:
> There are two reasons to try to get rid of HAVE_KERNEL_PLL. The public one
> is that it gets rid of the two-paths problem that sunk TESTFRAME. I might be
> able to bring that concept back and fully test-jig the ntpd code, which
> would be an extremely good thi
On Sun, Jan 08, 2017 at 06:35:58AM -0800, Hal Murray wrote:
>
> >> Using the term PLL.
> > But that's how the code is organized. In the absence of a PLL it doesn't
> > slew. Or am I missing something here?
>
> (at least) One of us is confused.
>
> The text from the blog:
> > There are two kin
On Sun, Jan 08, 2017 at 12:40:45AM -0500, Eric S. Raymond wrote:
> Hal Murray :
> >
> > I don't understand your section about the PLL. I think it's tangled up in
> > some bogus terminology. If you say a bit more, I'll try to sort things out.
>
> Alas, "say more" is not really actionable advice
y have misused the
term PLL in that sort of way.
If you had said something like:
There are two kinds of NTP hosts; one which makes small adjustments by
slewing the
clock, the other kind does not.
Then I would have been happy.
I'd like to understand why slew or not has signifi
Hal Murray :
>
> > Alas, "say more" is not really actionable advice. Can you tell me what
> > seemed bogus to you?
>
> Using the term PLL.
But that's how the code is organized. In the absence of a PLL it
doesn't slew. Or am I missing something here?
> > MacOS, Windows, and ... damn, I don't
> Alas, "say more" is not really actionable advice. Can you tell me what
> seemed bogus to you?
Using the term PLL.
> MacOS, Windows, and ... damn, I don't remember which BSD it was (not
> FreeBSD). What the oddballs lack is ntp_adjtime(). They can only step, not
> slew.
Slewing the clock i
. They can only step,
not slew.
> Are there other examples in this area? If not, I think it would be valuable
> to be able to run TESTFRAME using only the logs that were captured on a
> compatible system.
Complexification #1.
> Plan B would be to do something like cross compile usi
different paths through ntpd?
Are there other examples in this area? If not, I think it would be valuable
to be able to run TESTFRAME using only the logs that were captured on a
compatible system.
Plan B would be to do something like cross compile using header files that
match the system t
There's a new draft on the TESTFRAME debacle in the blog repo:
_drafts/testframe-the-epic-failure.ad
And this runs me out of the ideas I had queued up for blog posts.
Others should step up.
--
http://www.catb.org/~esr/";>Eric S. Raymond
Sometimes th
Hal Murray :
>
> e...@thyrsus.com said:
> >> As I understand things, the recent problem for TESTFRAME was the overlap
> >> between adjtimex and ntp_adjtime.
> > Not quite. It's the fact that with KERNEL_PLL enabled, the capture files
> > will have
e...@thyrsus.com said:
>> As I understand things, the recent problem for TESTFRAME was the overlap
>> between adjtimex and ntp_adjtime.
> Not quite. It's the fact that with KERNEL_PLL enabled, the capture files
> will have an event in the stream that won't replay pr
Mark: Heads up! Is it worth giving up Mac OS X for another shot at TESTFRAME?
Sadly, even that only gives us poor odds...
Hal Murray :
> I hope you are putting it on the back burner rather than totally giving up.
>
> As I understand things, the recent problem for TESTFRAME was th
I hope you are putting it on the back burner rather than totally giving up.
As I understand things, the recent problem for TESTFRAME was the overlap
between adjtimex and ntp_adjtime.
glib-2.23 says:
@code{adjtimex} is functionally identical to @code{ntp_adjtime}.
So that shouldn't
I just took TESTFRAME out behind the barn and shot it. Here's the
change comment:
TESTFRAME: Withdraw the TESTFRAME code.
There's an incompatible split between KERNEL_PLL and non-KERNEL_PLL
capture logs - neither can be interpreted by the replay logic that
would wo
Gary E. Miller :
> > Which I find strange. Preferred for portability, maybe, but
> > adjtimex() is strictly more powerful.
>
> really? How do you get that from this text:
>
>ntp_adjtime ()
>The ntp_adjtime() library function (described in the NTP "Kernel
>Appli‐ cation Progr
Yo Eric!
On Thu, 29 Sep 2016 00:07:25 -0400
"Eric S. Raymond" wrote:
> Gary E. Miller :
> > Yo Eric!
> >
> > On Wed, 28 Sep 2016 17:24:10 -0400
> > "Eric S. Raymond" wrote:
> >
> > > Remember, you can't even *build* the KERNEL_PLL version on a
> > > platform without adjtimex(2).
> >
>
> I don't have time to help with this now.
>
> I think you should keep working on TESTFRAME. At worst, we'll end up with a
> Linux only version. We'll probably learn more.
Alas, *I* think that pouring more effort into TESTFRAME looks at this point
like a losing propositio
Gary E. Miller :
> Yo Eric!
>
> On Wed, 28 Sep 2016 17:24:10 -0400
> "Eric S. Raymond" wrote:
>
> > Remember, you can't even *build* the KERNEL_PLL version on a platform
> > without adjtimex(2).
>
> The linux man page for adjtimex(2) says that ntp_adjtime() is preferred.
Which I find strange
Yo Hal!
On Wed, 28 Sep 2016 15:27:02 -0700
Hal Murray wrote:
> g...@rellim.com said:
> >> PLL option in the Linux kernel that gets included when you say:
> >> CONFIG_NTP_PPS=3Dy
> > We never use that PLL. No one should use that PLL with linux.
>
> [What do you mean "we", white man.]
>
>
g...@rellim.com said:
>> PLL option in the Linux kernel that gets included when you say:
>> CONFIG_NTP_PPS=3Dy
> We never use that PLL. No one should use that PLL with linux.
[What do you mean "we", white man.]
Why not? It works well on my systems.
*HPGPS(0).GPS.0 l 30
Yo Hal!
On Wed, 28 Sep 2016 15:09:46 -0700
Hal Murray wrote:
> Part of the problem is that we have a word tangle between my use of
> "kernel PLL" and your use of "KERNEL_PLL". I was referring to the
> PLL option in the Linux kernel that gets included when you say:
> CONFIG_NTP_PPS=y
We never
I think you should keep working on TESTFRAME. At worst, we'll end up with a
Linux only version. We'll probably learn more.
Part of the problem is that we have a word tangle between my use of "kernel
PLL" and your use of "KERNEL_PLL". I was referring to the PLL op
Yo Eric!
On Wed, 28 Sep 2016 17:24:10 -0400
"Eric S. Raymond" wrote:
> Remember, you can't even *build* the KERNEL_PLL version on a platform
> without adjtimex(2).
The linux man page for adjtimex(2) says that ntp_adjtime() is preferred.
What system has adjtimex(2) and not ntp_adjtime(2)?
RG
Try not to send mail in HTML; mutt can't read it.
John Bell :
>At the risk of sounding stupid (or at least uninformed), couldn't you
>capture TESTFRAME logs from the same hardware *booted on each kind of
>kernel* (with the kernels being otherwise identically configured),
>
iginal goal for TESTFRAME was to be able to collect a bunchof representative capture logs and reply them on every waf check,and along with the unit tests at the end of the build.The problem is that KERNEL_PLL as a build *variable* makes capturelogs non-portable, which means we can't have a single set
Mark: Heads up! TESTFRAME is probably almost pointless now, or at
least we can't count on it being fit for its original use until we
solve the slow-convergence problem well enough to dispense with the
KERNEL_PLL code.
Gary E. Miller :
> Hal Murray:
> > I don't see the pr
e...@thyrsus.com said:
> It would certainly simplify some ugly code if we knew that kernel receive
> timestamps are both standardized and actually implemented all across our
> target range.
There are socket options SO_TIMESTAMP, SO_TIMESTAMPNS, SO_TIMESTAMPING and
SCM_ variants. They add a tim
27 matches
Mail list logo
