The last release was the end of August.
--
These are my opinions. I hate spam.
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
e...@thyrsus.com said:
> I'm still going to take convincing. Like, with actual load numbers from one
> of those big servers.
I don't have any solid numbers. I just have a memory of comments about the
NIST servers being very busy with no comments saying that it wasn't a problem.
I'll see if I
Hal Murray :
>
> Eric said:
> > I concur. I would need to see actual measurements before I've convinced
> > that
> > ntpd with even a thosand client connections is a performance-degrading
> > load.
>
> I think there are two cases: popular public servers like NIST and everybody
> else.
>
> I
Eric said:
> I concur. I would need to see actual measurements before I've convinced that
> ntpd with even a thosand client connections is a performance-degrading load.
I think there are two cases: popular public servers like NIST and everybody
else.
I agree that the load on most servers is
Ian said:
> Bravo to Alpha isn't even mentioned in the draft: it speaks as though the
> two are the same client program.
Right. That's the whole point of Eric writing things down. We need to define
what happens there.
We could package Alpha and Bravo in the same program. Similarly, we coul
Achim, apologies for the lack of clarity.
500pps is TX. RX is slightly higher.
--
Sanjeev Gupta
+65 98551208 http://www.linkedin.com/in/ghane
On Mon, Jan 7, 2019 at 3:42 AM Achim Gratz via devel
wrote:
> Sanjeev Gupta via devel writes:
> > PPS is about 500/s, RX is 10% more than TX
> >
Eric said:
> Gary, for example, thinks we need bidirectional management protocols.
> Do we?
What's a management protocol?
Gary said:
> There is no simple "NTS client" and "NTS server". There is an NTS-KE that
> talks to both a client and to an NTPD server. Two mutually cooperating
> servers
Yo Ian!
On Sun, 6 Jan 2019 17:19:22 -0600
Ian Bruene via devel wrote:
> On 01/06/2019 05:11 PM, Gary E. Miller via devel wrote:
> > Which is a big doc, so I'm still not sure which part we are talking
> > about here...
>
> /devel/nts.doc is a new, and currently very small, file.
>
> You are t
Yo Hal!
On Sun, 06 Jan 2019 15:22:32 -0800
Hal Murray via devel wrote:
> Gary said:
> > Section 6 proposes a simple means to keep generating new short term
> > keys fomr old keys, so no need for further communication between
> > the NTS-KE and NTPD. Just once is enough.
>
> There needs to be
Gary said:
> Section 6 proposes a simple means to keep generating new short term keys fomr
> old keys, so no need for further communication between the NTS-KE and NTPD.
> Just once is enough.
There needs to be coordination when keys change.
It might be possible to have both NTS-KE and NTPD use
On 01/06/2019 05:11 PM, Gary E. Miller via devel wrote:
Which is a big doc, so I'm still not sure which part we are talking
about here...
/devel/nts.doc is a new, and currently very small, file.
You are thinking of the NTS draft.
That is a bad way to think of this. What you call "terrible
Yo Ian!
On Sun, 6 Jan 2019 17:01:08 -0600
Ian Bruene via devel wrote:
> On 01/06/2019 04:57 PM, Gary E. Miller via devel wrote:
> >> That is the one option that has been universally shot down as
> >> bad.
> > I'm not sure what option you refer to. Best in discussions like
> > these to keep in
On 01/06/2019 04:57 PM, Gary E. Miller via devel wrote:
That is the one option that has been universally shot down as bad.
I'm not sure what option you refer to. Best in discussions like these to
keep indirection to a minimum.
The one I had just been talking about as being implied by the or
Yo Ian!
On Sun, 6 Jan 2019 16:30:05 -0600
Ian Bruene via devel wrote:
> On 01/06/2019 02:55 PM, Gary E. Miller via devel wrote:
> > Seems to me that Section 6 of the proposed RFC defines this pretty
> > well. Once you can figure out who Clarlie (NTPD) and Delta (NTS-KE)
> > are.
>
> Partially
On 01/06/2019 02:55 PM, Gary E. Miller via devel wrote:
Seems to me that Section 6 of the proposed RFC defines this pretty well.
Once you can figure out who Clarlie (NTPD) and Delta (NTS-KE) are.
Partially. It gives an example of a way to do it, but no protocol or
message scheme; just what t
Gary E. Miller via devel :
> Yo All!
>
> I do not like this in nts.adoc:
>
> 4 boxes. My ASCII art is weak. C for client, S for server.
>
>Bravo Delta
>NTS client NTS server
> | |
>Alpha
Yo All!
I do not like this in nts.adoc:
4 boxes. My ASCII art is weak. C for client, S for server.
Bravo Delta
NTS client NTS server
| |
Alpha Charlie
NTP client -
Yo Ian!
On Sun, 6 Jan 2019 14:23:14 -0600
Ian Bruene via devel wrote:
> Charlie to Delta is the big acknowledged unknown.
Seems to me that Section 6 of the proposed RFC defines this pretty well.
Once you can figure out who Clarlie (NTPD) and Delta (NTS-KE) are.
> I think the word
> you might b
Fwd because I hit the wrong reply button.
Forwarded Message
Subject:Re: Let's get moving on NTS
Date: Sun, 6 Jan 2019 14:20:25 -0600
From: Ian Bruene
To: Eric S. Raymond
On 01/06/2019 01:38 PM, Eric S. Raymond via devel wrote:
So I think my job for the n
Gary E. Miller via devel :
> As for Alice and Charlie, please pick previously unused first names.
> Alice and Charlie are standard terms of cryptography, but are being used
> differently here in a confusing way.
I don't see this as a real problem. If you do, feel free to edit.
--
Sanjeev Gupta via devel :
> Interface is 100Mbps
> ntpsec is the only network service on the machine. gpsd runs locally
> CPU load is under 3%
> Hardware is a dual-core Pentium 4, 2800MHz, from about 2006
> Network traffic is under 100kbps
> PPS is about 500/s, RX is 10% more than TX
>
> Current
Yo Eric!
On Sun, 06 Jan 2019 19:23:35 +
"Eric S. Raymond via vc" wrote:
> C for client, S for server.
Incredibly easy to misunderstand. There are 3 types of parties in
each transaaction: client, NTS-KE, and NTPD. Can we use the standard
nomenclature instead of making up new ones?
Note I
Yo Eric!
On Sun, 6 Jan 2019 14:38:48 -0500 (EST)
"Eric S. Raymond via devel" wrote:
> Gary, for
> example, thinks we need bidirectional management protocols. Do we?
I never said, or meant to imply, 'bidirectional'. And 'management'
does not capture what I was thinking. Maybe 'coordination'?
Sanjeev Gupta via devel writes:
> PPS is about 500/s, RX is 10% more than TX
>
> Current client count is 18071
If your PPS number includes both the incoming and the outgoing packets,
then the average poll interval is slightly larger than 64 seconds, which
sounds about right for well-behaved client
This email is an attempt to bring together two different discussion
threads, one that I've been having with Hal Murray via private email and one
on signal chat.
We have our SOW from Cisco. It's time to get serious about
implementing NTS.
Everybody who hasn't hasn't should read the NTS draft:
ht
On Mon, Jan 7, 2019 at 2:23 AM Achim Gratz via devel
wrote:
> Sanjeev Gupta via devel writes:
> > root@ntpmon:~# ntpq -n -c direct -c mrulist | wc -l
> > 17306
> >
> > I am in the sg, in, and asia pools. v4 and v6. Server access is
> available
> > if you wish to poke around.
>
> What's the inte
Sanjeev Gupta via devel writes:
> root@ntpmon:~# ntpq -n -c direct -c mrulist | wc -l
> 17306
>
> I am in the sg, in, and asia pools. v4 and v6. Server access is available
> if you wish to poke around.
What's the interface speed to the outside world, how much of it is used
up by NTP and what's t
On Mon, Jan 7, 2019 at 12:57 AM Eric S. Raymond via devel
wrote:
> Achim Gratz via devel :
> > > Anyway, I think that thinking about them as separate parts will help
> our
> > > discussions.
> > > We should be able to improve performance on busy servers.
> >
> > It's been decades since I looked a
Achim Gratz via devel :
> > Anyway, I think that thinking about them as separate parts will help our
> > discussions.
> > We should be able to improve performance on busy servers.
>
> It's been decades since I looked at an NTP server that has enough
> clients to make me wonder about performance,
Gary E. Miller via devel :
> Yo Hal!
>
> On Sat, 05 Jan 2019 01:25:57 -0800
> Hal Murray via devel wrote:
>
> > The current code is a combined client and server. I think we should
> > split that into separate programs. Maybe not right away, but we
> > should at least start thinking that way.
>
Hal Murray via devel :
>
> The current code is a combined client and server. I think we should split
> that into separate programs. Maybe not right away, but we should at least
> start thinking that way.
>
> The server side is simple. It gets time from the system. There are a few
> other p
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 hints
in th
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 doesn't work as a client either.)
>
> ---
Hal Murray via devel writes:
> The current code is a combined client and server. I think we should split
> that into separate programs. Maybe not right away, but we should at least
> start thinking that way.
If you're going to give ntpd the djb treatment (ref. qmail) then that
split is the mos
35 matches
Mail list logo
