Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ntimed – NTPD replacement

github.com

Post reply on HN
Print view View original

41–50 of 109 posts

Re: Ntimed – NTPD replacement

#41

Post by jnbiche »

StillBored wrote: post #23
zzzcpan wrote: post #11

Earlier quoted context omitted.

Yeah. Especially considering that CPU overhead has very little value for time syncing program.

but latency, and jitter, are important in this application. Two things that discount most of the "safer" languages. After ignoring inmature ones, the field is pretty barren.

Yes, but if you're building an app for the future, then what excuse is there for not using Rust, which is both very low latency and very close to a 1.0 release?

I get that sometimes you just want to hack in a language that's familiar to you, but then call your project a fun side project and not the "NTPD replacement" (and yes, I know who phk is).

Re: Ntimed – NTPD replacement

#42

Post by msiebuhr »

gaadd33 wrote: post #4
ams6110 wrote: post #2

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?

Given PHK's interest in timekeeping I would guess it's going to be more accurate and precise than both ntp.org ntpd and OpenNTPD. However beyond that speculation, I don't know. It would be interesting to know.

Check his series of posts on the subject: http://phk.freebsd.dk/time/index.html

(TL;DR: Yes, he thought things through and are ntimed is implementing a few new tricks.)

Re: Ntimed – NTPD replacement

#43

Post by msiebuhr »

lazyjones wrote: post #3
ams6110 wrote: post #2

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?

> Why another from-scratch rewrote, And why oh why in C with so many safer options available today ..

AFAIK, PHK has written quite a bit of the FreeBSD kernel, most of Varnish (and a few other popular bits) in C.

I think it's safe to say that he's forgotten more about C/kernel/low-level/... programming than HN'ers will ever know.

Re: Ntimed – NTPD replacement

#44

Post by panic »

zanny wrote: post #32

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 y…

Are you speaking from experience writing system components in these languages? Lots of very high-quality software is written in C. Go and especially Rust are still moving targets. Depending on a separate compiler or runtime can hinder adoption and introduce errors when versions are out of sync.

Re: Ntimed – NTPD replacement

#45

Post by mrweasel »

lazyjones wrote: post #3
ams6110 wrote: post #2

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?

> Why another from-scratch rewrote, And why oh why in C with so many safer options available today ..

C programs are still much smaller than something written in many of the newer languages. This still matters for embedded software.

The portability of C is also huge because you want this running on a large number of hardware platforms. Everything from tiny home routers to the biggest server imaginable.

For something like an ntpd daemon you also want a language that many developers read and understand. C is used by more developers than pretty much any of the newer safer languages.

It might be old and weird, but C is still really hard to beat.

Re: Ntimed – NTPD replacement

#46

Post by easytiger »

atoponce wrote: post #21

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 o…

> 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.

Re: Ntimed – NTPD replacement

#47

Post by MaulingMonkey »

asveikau wrote: post #28
stonogo wrote: post #8

Earlier quoted context omitted.

The appropriate systems language for use on UNIX and Linux is C. The entire interface is based on C conventions. Sometimes, when all you have is nails, you really ought to reach for a hammer.

I seriously think the C-hater crowd on HN is just disappointed that they can't reason well about pointers. They can't write good C so no one can! It needs, like, more javascript, man. (Preemptive response to downvoters: please have a sense of humor about yourselves. :P)

> They can't write good C so no one can!

This is an accurate parody of my opinion. I'm unable to say "good C" with a straight face.

> I seriously think the C-hater crowd on HN is just disappointed that they can't reason well about pointers.

Let's be (hopefully) pessimistic and assume I'm a bottom 10th percentile programmer, and assume (I believe optimistically) that every programmer half an iota better than me is physically incapable of writing a single solitary buffer overflow, double free, use-after-free, or other pointer usage related bug. Perhaps they are robots!

I'm of the opinion that the remaining bottom 10th percentile remains a significant problem and security hazard. My continued employment with C++ seems to indicate we lack either the technology to detect, or the will to fire, this bottom 10th percentile. I feel that a hatred of C is a pragmatic step in helping reduce this problem, by reducing the usage of C by my fellow incompetents, by reducing the usage of C in general. Do you disagree? (I extend this stance to C++, despite it being my day job.)

http://www.cvedetails.com/vulnerabilities-by-types.php

Continuing the assumption - I'm disappointed that I can't reason well about pointers. I'm a bit more bummed about being in the bottom 10th percentile. I'm significantly more distressed that people can't reason well about people who can reason well about pointers - that, by virtue of being human, even they will make mistakes.

Being slightly less pessimistic: I'm fucking awesome. C isn't. What Dunning–Kruger effect?

Re: Ntimed – NTPD replacement

#48

Post by phkamp »

lazyjones wrote: post #3
ams6110 wrote: post #2

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?

> Why another from-scratch rewrote, And why oh why in C with so many safer options available today ..

1. C is not unsafe, if you use it as it was intended.

2. Because this is exactly the kind of task C was intended for: systems programming.

3. Because I want this to be a light-weight and portable program.

4. Because I have 30+ years of C-experience and happen to like the language.

Re: Ntimed – NTPD replacement

#49

Post by phkamp »

rtpg wrote: post #16
nwmcsween wrote: post #6

Earlier quoted context omitted.

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

Can you explain why abstraction is bad? Abstraction does _not_ mean your program will be slower. In fact, the opposite can happen, because the compiler has more context to work with, and can get rid of stuff. Haskell + stream fusion gives better results than well tuned C in some very typical situations http://research.microsoft.com/en-us/um/people/simonpj/papers... Even just comparing C++/C, C++'s templating mechanis…

Abstractions are certainly not "bad", there are many abstractions in Ntimed, it's also pretty object-oriented if you care to take a look.

This is more a matter of "the right language for the job" and for timing-critical systems programming running as root, that language is C.

And there are plenty of common abstractions I would love see added to the C language: basic linked lists, byte-endianess and packing for struct members, validity intervals for integers and FP variables (like Ada!)

Unfortunately my taste seems to be the direct opposite of ISO-C which have instead wasted time giving us another thread-API.

Re: Ntimed – NTPD replacement

#50

Post by phkamp »

zzzcpan wrote: post #11
SrslyJosh wrote: post #9

Earlier quoted context omitted.

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.

Yeah. Especially considering that CPU overhead has very little value for time syncing program.

It's always a good idea to do a quick back-of-the-envelope calculation before generalizing like that:

About 2 million servers were sold world-wide in 2014Q2

Assume 25% runs UNIX and NTPD -> half a million servers

Assume NTPD uses 0.1% of machine resources -> 500 fully loaded servers.

Assume 100W/server -> 50 kW

50kW for half a year -> 220,000 kWh

Assume 500g CO2/kWh -> 110 tons of CO2

QED: I think CPU overhead is a very relevant concern for time synching programs.

Post reply on HN