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

51–60 of 109 posts

Re: Ntimed – NTPD replacement

#51

Post by lazyjones »

phkamp wrote: post #50
zzzcpan wrote: post #11

Earlier quoted context omitted.

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

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

Bold assumption. It uses 0.0006% on my slow 6 years old box (over 13 days uptime). Let's be generous and say it's 0.001%, then you get 1.1 ton of CO2, which is the equivalent of the production of about 32.8 Kg of beef. I don't think such dramatic conclusions can be made from those facts.

Re: Ntimed – NTPD replacement

#52

Post by [deleted] »

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…

[deleted]

Re: Ntimed – NTPD replacement

#53

Post by perlgeek »

kolev wrote: post #35
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…

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

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.

Re: Ntimed – NTPD replacement

#54

Post by phkamp »

lazyjones wrote: post #51
phkamp wrote: post #50

Earlier quoted context omitted.

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

> Assume NTPD uses 0.1% of machine resources -> 500 fully loaded servers. Bold assumption. It uses 0.0006% on my slow 6 years old box (over 13 days uptime). Let's be generous and say it's 0.001%, then you get 1.1 ton of CO2, which is the equivalent of the production of about 32.8 Kg of beef. I don't think such dramatic conclusions can be made from those facts.

First, I doubt your kernels statistics actually account correctly at that level of precision. (If it does, that alone would waste a lot of CPU cycles!)

Second, have you checked the memory footprint of NTPD ? "machine resources" is more than CPU cycles.

And don't forget: That number was one quarters purchase of servers, running for half a year. All the servers bought in 2010, 2011, 2012, 2013 and the other half of the year were not included.

Things add up.

Re: Ntimed – NTPD replacement

#55

Post by xorcist »

jnbiche wrote: post #41
StillBored wrote: post #23

Earlier quoted context omitted.

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

Please start by showing us the PLL in Rust (details are available at phk's blog) and reason about how those changes affects the workings of the program. Is it more readable? Less? More exact? That I would be interested in.

Re: Ntimed – NTPD replacement

#56

Post by jnbiche »

jnbiche wrote: post #40
asveikau wrote: post #28

Earlier quoted context omitted.

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)

You realize that the most vociferous of those decrying this language choice come from the proponents of a language that has 3 different types of pointers, right? You should check out Rust and Go. Their users are most definitely among those who fail to understand C pointers.

Oops, that was supposed to be "are not among those who fail". I'm a Rust supporter and think Go is also a better alternative to C in many instances.

My point was, Rust supporters have no problems understanding pointers.

Re: Ntimed – NTPD replacement

#58

Post by 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).

Re: Ntimed – NTPD replacement

#59

Post by phkamp »

nullc wrote: post #58

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

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.

Re: Ntimed – NTPD replacement

#60

Post by 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.
Post reply on HN