> We've established not so long ago that a single NTP server can serve a lot of
> clients. The number of servers is driven by the network topology more
> likely, i.e. say you want one NTP server per network span or subnet, so the
> server has low latency to each of its clients and doesn't send
e...@thyrsus.com said:
>> My strawman for REFCLOCKD is something like the touring test.
>> You can't tell the difference by poking around with ntpq. (Maybe
>> you don't get to poke too deep.)
> It'd need its own UDP port.
I don't understand. All I was trying to say is that splitting out the
I will be seriously disappointed if you drop that code.
You need it to verify that you don't need it.
Some of us are interested in that level of detail. If you start removing
things like that, I will probably spend less time here.
Your comments in the tour document are biased. (I'm
Hal Murray :
>
> My strawman for REFCLOCKD is something like the touring test. You can't tell
> the difference by poking around with ntpq. (Maybe you don't get to poke too
> deep.)
It'd need its own UDP port.
> There are two parts to the refclock code.
>
> The first operates on the second
My strawman for REFCLOCKD is something like the touring test. You can't tell
the difference by poking around with ntpq. (Maybe you don't get to poke too
deep.)
There are two parts to the refclock code.
The first operates on the second time scale. The main thread calls the
refclock
Hal Murray :
>
> Eric said:
> > I meant to mention that there are actually *two* big benefits in prospect
> > from a Go port. The obvious one is being able to junk a lot of fiddly,
> > error-prone C memory-management stuff.
>
> I'm actually surprised that you haven't simplified a lot of that
Daniel Franke via devel :
> One thing ntpd does do (both in NTP Classic and in NTPsec) is fetch
> kernel timestamps on incoming packets using the SO_TIMESTAMP option.
> This is different from hardware timestamps; they're not generated by
> the NIC, they're generated by the kernel at the moment the
Eric said:
> I meant to mention that there are actually *two* big benefits in prospect
> from a Go port. The obvious one is being able to junk a lot of fiddly,
> error-prone C memory-management stuff.
I'm actually surprised that you haven't simplified a lot of that yet.
There are several
Ian Bruene via devel :
> On 3/2/19 9:42 AM, Eric S. Raymond via devel wrote:
> > REFCLOCKD benefits way down, cost almost unchanged. Every time I model
> > this in my head the same answer comes out: bad idea. I think we have
> > better complexity-reduction attacks available, like translating the
Yo Kurt!
On Mon, 4 Mar 2019 00:35:24 +0100
Kurt Roeckx wrote:
> > > But it is present in chrony. It supports both interleaved mode
> > > and hardware timestamping.
> >
> > I'm looking for it, but can not find it. Can you point out where?
> >
> > I do see that chronyd has a "PTP hardware
On Sun, Mar 03, 2019 at 03:30:53PM -0800, Gary E. Miller via devel wrote:
> Yo Kurt!
>
> On Mon, 4 Mar 2019 00:19:44 +0100
> Kurt Roeckx via devel wrote:
>
> > > Actually getting timestamps from the NIC is fairly involved. The NIC
> > > has its own clock and its own oscillator, which has to
Yo Kurt!
On Mon, 4 Mar 2019 00:19:44 +0100
Kurt Roeckx via devel wrote:
> > Actually getting timestamps from the NIC is fairly involved. The NIC
> > has its own clock and its own oscillator, which has to carefully be
> > kept in sync with the system clock. Furthermore, all the APIs for
> >
On Sun, Mar 03, 2019 at 05:59:11PM -0500, Daniel Franke wrote:
> On Sun, Mar 3, 2019 at 8:45 AM Kurt Roeckx via devel wrote:
> > On Sun, Mar 03, 2019 at 05:23:31AM -0800, Hal Murray wrote:
> > >
> > > k...@roeckx.be said:
> > > > If this is something you're worried about, this can be solved with
On Sun, Mar 3, 2019 at 8:45 AM Kurt Roeckx via devel wrote:
> On Sun, Mar 03, 2019 at 05:23:31AM -0800, Hal Murray wrote:
> >
> > k...@roeckx.be said:
> > > If this is something you're worried about, this can be solved with the
> > > interleave mode, which was removed.
> >
> > How well does it
On 3/2/19 9:42 AM, Eric S. Raymond via devel wrote:
REFCLOCKD benefits way down, cost almost unchanged. Every time I model
this in my head the same answer comes out: bad idea. I think we have
better complexity-reduction attacks available, like translating the
whole thing to Go to get rid of a
Yo Hal!
On Sat, 02 Mar 2019 22:45:05 -0800
Hal Murray via devel wrote:
> Gary said:
> >> Which ones do you intend to relax? And in any case you don't need a
> >> whole CA, you can pin a self-signed cert and still do full
> >> validation on it.
> > Except we can't. The current NTPsec code
Yo Hal!
On Sat, 02 Mar 2019 23:49:14 -0800
Hal Murray via devel wrote:
> devel@ntpsec.org said:
> > Partial validation means you don't follow the cert chain to the
> > root. In the off-net scenario, it means you stop folloing the chain
> > when you'd have to go outside the network perimeter
On Sun, Mar 03, 2019 at 10:25:31PM +0100, Achim Gratz via devel wrote:
> Kurt Roeckx via devel writes:
> > I don't see how it can work with the current pool system. You look
> > something up like pool.ntp.org and get some IP addresses. But none
> > of those will have a certificate for
Kurt Roeckx via devel writes:
> I don't see how it can work with the current pool system. You look
> something up like pool.ntp.org and get some IP addresses. But none
> of those will have a certificate for pool.ntp.org, so the
> verification of the certificate will fail.
You will still look up a
On Sun, Mar 03, 2019 at 08:56:55PM +0100, Achim Gratz via devel wrote:
> Hal Murray via devel writes:
> > There is no security in the pool anyway, so let's put that discussion
> > aside for a while.
>
> I'd take exception with that statement. If the pool was upgraded to use
> NTS one way or the
Hal Murray via devel writes:
> I thought most systems came with a collection of trusted/root certificates.
> What do I have to go outside-the-network to get?
You'll have to check the cert chain until you hit one of those trust
anchors that can't be otherwise checked since they're the start of
Hal Murray via devel writes:
> There is no security in the pool anyway, so let's put that discussion
> aside for a while.
I'd take exception with that statement. If the pool was upgraded to use
NTS one way or the other, it _would_ provide some extra security over
the status quo. It's a
Kurt Roeckx :
> If this is something you're worried about, this can be solved with
> the interleave mode, which was removed.
The interleave move was removed because it was broken. There was a small but
fatal error in the packet construction. I don't remember the details, but
Damiel Franke did
Hal Murray :
> > Let me take a different tack: can we move the aut computation off path?
>
> Nope. The auth includes the whole packet. Can't do the auth until you know
> the time that you are going to put in the packet.
I was expecting that answer, but the question hd to be asked.
> We can
On Sun, Mar 03, 2019 at 05:23:31AM -0800, Hal Murray wrote:
>
> k...@roeckx.be said:
> > If this is something you're worried about, this can be solved with the
> > interleave mode, which was removed.
>
> How well does it work?
It works great, the errors are much smaller when it's enabled.
>
k...@roeckx.be said:
> If this is something you're worried about, this can be solved with the
> interleave mode, which was removed.
How well does it work?
Is there an option to get a kernel timestamp on transmit packets?
--
These are my opinions. I hate spam.
On Sat, Mar 02, 2019 at 09:23:51PM -0800, Hal Murray via devel wrote:
> *) There is actually one interesting point that authentication makes more
> interesting. On receive, we get a time stamp when the packet arrives. We
> can
> take all day to inspect the packet and run authentication code.
> Let me take a different tack: can we move the aut computation off path?
Nope. The auth includes the whole packet. Can't do the auth until you know
the time that you are going to put in the packet.
We can measure how long it takes and advance the time to compensate.
--
These are my
Hal Murray :
>
> e...@thyrsus.com said:
> >> My big concern is that nobody else seems to be testing it. There may be
> >> dragons that I haven't poked.
> > Understood. Unfortunately I myself can't be much help here - my outside
> > view
> > of NTP is still weak, I have only limited ability to
29 matches
Mail list logo
