Yo Daniel!
On Thu, 29 Sep 2016 20:30:49 -0400
Daniel Franke wrote:
> On Sep 29, 2016 8:22 PM, "Eric S. Raymond" wrote:
> >
> > Gary E. Miller :
> > > > But we have one mission imperative that trumps drop-in
> > > > replacement: security. And what makes these modes targets for
> > > > removal
On Sep 29, 2016 8:22 PM, "Eric S. Raymond" wrote:
>
> Gary E. Miller :
> > > But we have one mission imperative that trumps drop-in replacement:
> > > security. And what makes these modes targets for removal is that,
> > > according to Daniel, there are fundamentally impossible to secure.
> >
> >
Gary E. Miller :
> > But we have one mission imperative that trumps drop-in replacement:
> > security. And what makes these modes targets for removal is that,
> > according to Daniel, there are fundamentally impossible to secure.
>
> I would split that hair. Maybe ntpd could still send broadcast
Yo Eric!
On Thu, 29 Sep 2016 19:39:28 -0400
"Eric S. Raymond" wrote:
> Gary E. Miller :
> > On Thu, 29 Sep 2016 19:19:28 -0400
> > "Eric S. Raymond" wrote:
> >
> > > So, the question for our domain experts is, are there any serious
> > > use cases for broadcast modes? They cost a lot in con
Gary E. Miller :
> On Thu, 29 Sep 2016 19:19:28 -0400
> "Eric S. Raymond" wrote:
>
> > So, the question for our domain experts is, are there any serious use
> > cases for broadcast modes? They cost a lot in configuration and
> > code complexity; it would be nice to just drop them. How much
> > s
Yo Eric!
On Thu, 29 Sep 2016 19:19:28 -0400
"Eric S. Raymond" wrote:
> So, the question for our domain experts is, are there any serious use
> cases for broadcast modes? They cost a lot in configuration and
> code complexity; it would be nice to just drop them. How much
> screaming might that c
Mark, heads up! Possible policy/PR issue.
I have merged Daniel Franke's refactoring of the NTP protocol machine.
It seems to work. However, there are some operation modes of Classic
that may be broken and need fixing.
After the refactor:
(1) Interleave mode is outright gone. This is OK, as it
Yo All!
Below are the 24 hour results for --disable-kernel-pll on a RasPi 3
with Uputronics HAT.
With --disable-kernel-pll
Local Clock Local Clock Local ClockPPS PPS
Poll Freq Offset 90% Jitter 90% Stability 90% Offset 90% Jitter 90%
1 1.36 ppm 0.75µ
Yo Daniel!
On Thu, 29 Sep 2016 14:34:08 -0400
Daniel Franke wrote:
> On Sep 29, 2016 2:23 PM, "Gary E. Miller" wrote:
>
> > Then maybe a worth while experimment to copy the kernel PLL into
> > ntpd to see how it works there?
>
> I can't conceive of how you'd do that. It's too tightly integr
On Sep 29, 2016 2:23 PM, "Gary E. Miller" wrote:
> Then maybe a worth while experimment to copy the kernel PLL into ntpd
> to see how it works there?
I can't conceive of how you'd do that. It's too tightly integrated with the
rest of the kernel timing subsystem and other internal kernel APIs.
__
Yo Daniel!
On Thu, 29 Sep 2016 10:06:01 -0400
Daniel Franke wrote:
> On 9/28/16, Gary E. Miller wrote:
> > The knerel PLL and the ntpd userspace PLL are supposed to be using
> > the same algorithm and constants. Might be worth checking if the
> > constants are still the same.
>
> They aren'
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 work for the
Daniel Franke :
> This whole module is a big mess of undefined behavior.
You're right. I've just deleted it, quoting you on the problems in
the change comment. Similar ones were present in the gettimeofday()
version because the thing was a relic from before the 64-bit
transition.
If we need a b
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
On 9/28/16, Gary E. Miller wrote:
> The knerel PLL and the ntpd userspace PLL are supposed to be using the
> same algorithm and constants. Might be worth checking if the constants
> are still the same.
They aren't. In ntp_loopfilter.c, we have
#define CLOCK_PLL 16. /* PLL loop gain (l
This whole module is a big mess of undefined behavior.
If you're going to store time as a count of nanoseconds, then of
course you're going to overflow a 32-bit integer quickly. 'long' is 32
bits on most 32-bit ABIs. You want all your working variables to be
int64_t. The correct way to express an
16 matches
Mail list logo
