
Ntimed – NTPD replacement - 925dk
https://github.com/bsdphk/Ntimed
======
atoponce
If Ntimed separates out the client from the daemon, so I can install just the
client package only, IMO that will be a big win for computer time
synchronization.

One thing that has always bothered me with the NTP project, is the lack of a
separate daemon and client. If you want the NTP project's client, then you
must also install the daemon, even if it is listening only on localhost, or if
you opt to not start it up on boot. It still must be installed though.

On my Debian system, I only have the following "clients" available:

* libnet-ntp-perl

* openntpd (which also installs a listening daemon)

* python-ntplib

In most cases, such as on my laptop, workstations, and embedded systems, I
don't want the complexities of a full blown daemon running, nor do I want to
manage firewalling and configuring the daemon to listen on localhost to
prevent remote queries. The only other two options are programming libraries.

As such, I'm looking forward to systemd-timesyncd. It implements a simple SNTP
client to synchronize your clock. As such, the full NTP complexity is not a
concern. This is very likely an attractive scenario for most GNU/Linux
installations, as most users won't be interested in running an NTP daemon
synchronizing other NTP client clocks.

~~~
easytiger
> One thing that has always bothered me with the NTP project, is the lack of a
> separate daemon and client.

> In most cases, such as on my laptop, workstations, and embedded systems, I
> don't want the complexities of a full blown daemon running

Pretty confused. Why would you care about a code path that isn't executed? Are
upset about losing a few kb of disk space? What is the alternative to "a full
blown daemon". Can you demonstrate how that is an issue for anyone?

Your comment also shows a fundamental misunderstanding of NTP. It's a peer-to-
peer protocol in many use cases, as is PTP so instances have to run as client
& server.

~~~
Ricapar
It's just good security practice.

Even if the code path is never intended to be executed, there are bugs in code
that could lead to it.

Yes, it's a P2P protocol, but when you're managing a bunch of servers, you
don't use it as such.

You set up one server in your environment (time.example.com) and have all your
boxes sync to that.

Why would appserv.example.com EVER need to be able to accept NTP connections
from anyone else?

~~~
mkhpalm
You are looking for ntpdate executed regularly from a scheduled task. Its a
sawtooth drift/snap pattern but it seems to be good enough for MS.

That said, a slightly configured ntp doesn't ever accept ntp connections from
anyone else. Thats not like a requirement or anything.

------
ams6110
According to the OpenNTPD web page, "The portable version is outdated and in
need of a maintainer."

Why another from-scratch rewrote, instead of helping with that project,
especially when it was also motivated by an aversion to the "100,000 KLOC" in
the ntp.org ntpd?

~~~
lazyjones
> _Why another from-scratch rewrote,_

And why oh why in C with so many safer options available today ..

~~~
nwmcsween
What safer options are there with equal size, overhead (read: none) and not
full of layers upon layers of abstractions?

~~~
SrslyJosh
That sounds like you're implying that safety has no value, the only "overhead"
worth considering is CPU cycles (what about the programmer's
time/effort/sanity?), and that abstractions have negative value.

I don't think that's how you're supposed to software.

~~~
threeseed
It's a core operating system component not some web app.

Overhead is important since Linux is designed to run on a whole spectrum of
devices. Abstractions mean you are bringing in more code i.e. greater
complexity, space, overhead. And frankly nobody could care less about
programmer's time/effort/sanity in this case. It is a tightly focused,
specific utility that shouldn't see too many changes after a certain point.

~~~
moe
_Overhead is important since Linux is designed to run on a whole spectrum of
devices._

Like the difference between a ntpd.c vs ntpd.go is going to matter for
anyone...

If you really find yourself stuck with an embedded device small enough that a
few megabytes of RAM matter then you can still use the old C implementations,
it's not like they are going away.

 _Abstractions mean you are bringing in more code i.e. greater complexity,
space, overhead._

In this case abstractions mean you can probably write the whole thing in under
2 kloc, get memory safety for free, and base it on a network stack that other
people actually use and debug independently.

 _It is a tightly focused, specific utility that shouldn 't see too many
changes after a certain point._

Umm. Yea. Right. Tell that to the ntpd guys with their 100kloc codebase...

~~~
mcgoo
The jitter introduced by garbage collection in a go implementation could well
be significant, even with the new "never pause the mutator for more than 1ms"
guarantee.

~~~
moe
How much of the code is actually sensitive to interruptions?

Why not write _that_ part in C and leave the rest to the more suitable
language?

I would guess that's a rather small portion of the codebase, essentially the
callouts to adjtime().

I don't buy into the low-latency FUD. C isn't a magical realtime language
either; what happens when the system is under high load? What about delays in
the kernel/network stack?

As a layman I would think incoming frames will have to be stamped with a
hardware high resolution timestamp at arrival anyway, regardless of the
language. And yes, this internal timestamp will have to be compared
immediately before setting the hwclock. I would argue this is the only part
that really needs to be written in a GC free language.

I might be wrong on this, but I'd like to see a stronger argument than "could
well be significant" for writing yet another generation of a baseline system
daemon in an unsafe language...

And speaking of latency: If this really is such an issue, why hasn't NTP long
been moved into the kernel?

------
jumanji
I think there is too much negativity here. Thank you phk for developing free
and open source software. Don't let the complainers wear you down.

------
nullc
This is interesting work,

NTP is a surprisingly large piece of software considering it's narrow task...
and at this point rather crufty, ... e.g. in spite of having a ton of
monitoring code that keeps turning up vulnerabilities, it's rather hard to
monitor.

It has complex filtering, but still can perform rather poorly (esp with broken
servers available). etc.

And accurate and (increasingly-) precise time keeping is mission (and, in some
cases, security) critical to many applications.

Time really should be a solved problem but sadly it's not. Though fairly
accurate temperature compensated oscillators are not terribly expensive, they
don't find their way into typical server clocks. Many public ntp servers give
bogus data. etc.

Meanwhile, kernel timekeeping has become more sophisticated. I suppose one of
the principles in varnish was letting the kernel do its job, so there may be
some opportunity to apply that principle here too.

So I think there is plenty that PHK could do interesting here while keeping
the codebase quite focused and compact.

I do wonder how he would compare this effort to some of the other NTP
alternatives (in particular chrony).

~~~
phkamp
I'm not keen on saying too much about Chrony, I'd rather let people without a
stake in the game provide comparisons.

But obviously: if I had throught it was just the thing, I wouldn't have
started writing Ntimed.

I also don't expect Ntimed to out-compete Chrony, and if it did, I'd have to
start a fourth alternative myself, to keep competition healty.

A very large part of NTPDs problem was that there were no competition, which
meant that everything got crammed into NTPD, come hell or 300KLOC.

We saw this also with GCC, which had become a stagnated arrogant monopoly, and
suddenly LLVM forced them to care about users again.

Having competing projects is good thing, and I hope Chrony sees things that
way too.

------
cnst
Well, so far -- this is only a client, so, it's not really much of a unique
replacement of anything just yet.

Apart from OpenBSD's ntpd (OpenNTPD) --
[http://bxr.su/OpenBSD/usr.sbin/ntpd/](http://bxr.su/OpenBSD/usr.sbin/ntpd/)
\-- which is a compete ntpd client/server solution done the OpenBSD way since
some 2004, there's also DragonFly's dntpd --
[http://bxr.su/DragonFly/usr.sbin/dntpd/](http://bxr.su/DragonFly/usr.sbin/dntpd/)
\-- a client-only ntpd, originally written by Matt Dillon in 2005 --
[http://lists.dragonflybsd.org/pipermail/commits/2005-April/2...](http://lists.dragonflybsd.org/pipermail/commits/2005-April/242742.html)
\-- e.g. nearly concurrently with OpenNTPD development and polish.

Oh, yeah, and PHK hates OpenNTPD. I'm surprised he apparently has recently
used such nice words about OpenNTPD! One of the main reasons he was against
OpenBSD's sensors framework going into FreeBSD was the timedelta sensor
support, a type of sensor which basically tells you the offset of your system
clock compared to some other clock source (e.g.
[http://mdoc.su/o/nmea.4](http://mdoc.su/o/nmea.4) /
[http://bxr.su/OpenBSD/sys/kern/tty_nmea.c](http://bxr.su/OpenBSD/sys/kern/tty_nmea.c)),
and these timedelta hardware sensors are used by OpenBSD's ntpd to set the
correct time, which seems to do the job just fine.

------
zimbatm
The biggest annoyance with NTPD is that it will give up synching if the time
delta is too large. It just shows that the software was primarily coded to be
a server. If you just use NTPD to keep your machine times in sync `chrony` is
a better solution for now.

~~~
nullc
Giving up is also a security feature.

Whats more likely? your system clock sped up by a factor of 2 and everything
kept working, or some guy on your network is trying to dork around with your
time so he can bypass some time limited authentication?

Of course, the software needs to correctly handle cases like suspend where the
time may honestly need to step. If it doesn't thats a short coming of the
software, not a reason to eagerly make "presumed impossible" leaps just
because some unauthenticated packets on the network tell you to.

------
zanny
Why the hell would you write this in C, when so many other programming
languages exist now. I mean, you could write a time sync program in Python
today. But if you still want to be maximally performant since you intend to
run on millions of computers, Go and Rust are new and fresh and memory safe,
and modern C++ is great too. A lot better than malloc and pointer arithmetic.

I get that the original ntpd is almost 20 years old, and opentpd is about a
decade old, and back then writing every in C was forgivable, because the
alternates were not as far ahead in every metric possible as they are today.
Now it just looks like someone trying to use Cobol or Fortran in new
production products.

~~~
kolev
I think Rust should be the default choice from projects like this going
forward.

~~~
perlgeek
While I agree with the motivation behind your statement, I don't think Rust
has proven itself yet to the degree that it should be a default choice for
anything.

Remember that compilers and runtime libraries can have bugs too, and new ones
tend to have more bugs than those maintained over some time.

~~~
kolev
Yes, runtimes and libraries can have bugs, too, agreed, but at least you will
have to just recompile with the patched version vs having to fix and test your
code as fast as possible. It's more efficient as well as fixing the core will
benefit many (well, of course, that would have compromised many as well... to
start with).

