Achim Gratz <strom...@nexgo.de>:
> …or move the refclocks out of ntpd altogether and use some shared memory
> or mailbox system to have ntpd have a look at the timestamp stream from
> each refclock.
Yeah, this is one of my longer-term plans. It was in the original technical
proposal I wrote 18 months ago, labeled REFCLOCKD.
> I think the appeal would be to use multiple cores on a multiprocessor,
> ostensibly not to cut down on the response time, but rather to shorten
> the long tail of the distribution. Whether or not multiple threads or
> processes achieve that objective needs investigation of course.
As I just wrote, I want to see measurements before I invest in complexity.
Especially since one of the things we know is that the servers deployed
out there (a) are *not* using concurrency, and (b) nobody is identifying
poor performance under load as a pain point.
Therefore I'm going to need persuading that high load is even a real
problem, let alone that concurrency is the right solution.
> Your experience with the rasPi is maybe just the hammer that makes all
> problems look like nails when in reality you'll also need to deal with
> welds, screws, press-fit, snap-in and folded cardboard.
Fair point. You may be right that I'm being too optimistic here.
> They are not yet cheap enough to have a single server per function, at
> least not on iron. Virtualization and containerization hasn't yet
> diffused into all places so you can't even assume that NTP is isolated
> to one VM or container.
Not that that would matter - VMing doesn't magically make more cycles
available, in fact quite the reverse.
> You seem to be arguing from the standpoint of whether or not ntpd keeps
> the local clock in sync (or at least that's my impression). Let's
> assume you already ascertain that, then the question becomes how many
> clients you can serve that time with some bounded degradation under
> various load conditions. For NTP the response time is somewhat
> critical, but even more important is that the variability of the
> response time should be minimized. This is of course where it gets
> tricky to even measure…
Yes. On the other hand, I repeat: we have the real-world information
that "Help! My time-service performance is degrading under load!" is
*not* a theme being constantly sounded on bug-trackers or in time-nuts
or elsewhere. In fact I've never seen this complaint even once.
The simplest explanation for this dog not barking is that there's no
burglar - that is, you have to load your timeserver to a *ridiculous*
extent before performance will degrade enough to be visible at the
scale of WAN or even LAN time service.
I think this explanation is very likely to be the correct one. If
you want to persuade me otherwise, show me data.
--
<a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>
_______________________________________________
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
