g...@rellim.com said:
> Looks like NTPsec really need SNTP to support Windows clients, and the
> accuracy needs are minimal.
SNTP and real NTP use the same packet formats so we can already support
Windows clients.
--
These are my opinions. I hate spam.
___
e...@thyrsus.com said:
>> How are you going to test MS-SNTP?
>> The old code, called out to a MS server to sign the response. That
>> tied up the server. The people who needed it were running low
>> volume so they were OK with that.
> That's an issue I was not aware of, and makes me want to dro
>> What is the status of your simple setup doc?
> Ready to ship. Your review and corrections were the last polishing step I
> thought it needed.
I thought we were waiting for the pool/restrict bug to get fixed.
Has it been updated to use the pool?
What's the URL?
--
These are my opinions.
e...@thyrsus.com said:
>> It might be useful to make sure that any workaround for
>> OS X is general enough to handle another case.
> It will be. We just fall back to the old BSD adjtime(2) call, which
> everybody (even OS X) has.
Thanks. That explains why/how it works and why the results are s
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 an event in the stream that won't replay properl
Mark, there's a "what platforms do we care about?" question here.
Hal Murray :
>
> I think I see the confusion.
>
> My version of "remove" was remove the #ifdef and leave the code. (and
> cleanup any #else...)
No, I got that. The problem is, then we don't build on systems without
sys/timex.h
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 properly on a
> non-KERNEL_PLL s
I think I see the confusion.
My version of "remove" was remove the #ifdef and leave the code. (and
cleanup any #else...)
KERNEL_PLL is an alias for HAVE_SYS_TIMEX_H
sys/timex.h is where ntp_adjtime and ntp_gettime come from
Do we currently run on any systems without ntp_adjtime from sys/timex
Hal Murray :
>
> g...@rellim.com said:
> >> I'd vote for getting rid of KERNEL_PLL.
> > Me too, but the alternative has to not suck. The last test remove was a
> > terrible failure.
>
> What "test remove" was that?
I implemented a --disable-kernel-pll option so Gary could test with
KERNEL_PLL
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 the overlap
> bet
Yo Hal!
On Wed, 05 Oct 2016 11:55:36 -0700
Hal Murray wrote:
> g...@rellim.com said:
> >> I'd vote for getting rid of KERNEL_PLL.
> > Me too, but the alternative has to not suck. The last test remove
> > was a terrible failure.
>
> What "test remove" was that?
Eric added --disable-kernel
Yo All!
There has been an interesting discussion of late on time-nuts about
how bad Windows timekeeping is. This one snippet is very relavant to
current NTPsec plans:
From: Tim Shoppa
> I agree that the built in Microsoft tools are SNTP only and will not
> work at the 15ms level.
Looks like N
g...@rellim.com said:
>> I'd vote for getting rid of KERNEL_PLL.
> Me too, but the alternative has to not suck. The last test remove was a
> terrible failure.
What "test remove" was that?
--
These are my opinions. I hate spam.
___
devel mailing
Yo Hal!
On Wed, 05 Oct 2016 02:20:58 -0700
Hal Murray wrote:
I'd vote for getting rid of KERNEL_PLL.
Me too, but the alternative has to not suck. The last test remove
was a terrible failure.
RGDS
GARY
---
Gary E. Miller R
How timely and apropos! http://xkcd.com/1742/
- JDB
> On October 5, 2016 at 2:33 AM Mark Atwood wrote:
>
>
> we need to be packaged for debian, rasbian, ubuntu, gentoo, redhat, and
> suse for 1.0 and be working towards getting into their distribution system
> (apt, yum, etc)
>
> On Wed,
Hal Murray :
> I have no strong opinion about red vs green vs blue.
I don't either. I guess in general I lean towards waiting a little longer
and having a more impressive feature list. But I laid out scenarios for
nearer-term releases because there might be PR or fundraising reasons
to do that.
Mark Atwood :
> I want to have a conversation with our new funding sources about their
> expectations, as i ponder Case Nightmare Red/Green/Blue
Roger. Just for the record, I'm *not* expecting the 1.0 release to
materialize legions of ravening Great Old Ones.
--
http://www.catb.o
I have no strong opinion about red vs green vs blue.
I think it would make more sense to have a high level description of what you
want for a release. If you had that, I think it would be easy to pick a
color.
There are probably other areas that are just as important.
Are you planning to fix
I want to have a conversation with our new funding sources about their
expectations, as i ponder Case Nightmare Red/Green/Blue
On Wed, Oct 5, 2016, 10:08 AM Eric S. Raymond wrote:
> Mark Atwood :
> > we need to be packaged for debian, rasbian, ubuntu, gentoo, redhat, and
> > suse for 1.0 and be
Mark Atwood :
> we need to be packaged for debian, rasbian, ubuntu, gentoo, redhat, and
> suse for 1.0 and be working towards getting into their distribution system
> (apt, yum, etc)
Yes, we do.
That doesn't imply a choice among Cases Red/Green/Blue, though. Do you
have an opinion or judgment ab
20 matches
Mail list logo
