Ntimed – NTPD replacement • Hacker News Board

Re: Ntimed – NTPD replacement

#61

Post by ta0967 » Mon, Dec 22, 2014, 12:44 PM UTC

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.

you should publish a Rust version of Ntimed, then its advantages would be obvious and nobody would touch C again.

while i'm here, compare the tone of your comment with that of the following (lifted from somebody's comment in another HN thread):

Personally I wish this was done with $otherlang.. But then again I'm not writing it myself, so I can't really complain.

Re: Ntimed – NTPD replacement

#62

Post by lttlrck » Mon, Dec 22, 2014, 12:49 PM UTC

vertex-four wrote: post #29

threeseed wrote: post #12

Earlier quoted context omitted.

Rust isn't even at version 1.0 yet and is probably a year away from being in a "suitable for production" state. System time is far, far too critical to take chances with.

On the other hand, this program is going to take a year or so before anybody seriously considers using it, simply due to the fact that few people are going to do something other than their distro default for such a small part of their system.

waiting for rust to hit production readiness will not avoid that.

Re: Ntimed – NTPD replacement

#63

Post by Ricapar » Mon, Dec 22, 2014, 2:02 PM UTC

easytiger wrote: post #46

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

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?

Re: Ntimed – NTPD replacement

#64

Post by mcgoo » Mon, Dec 22, 2014, 2:22 PM UTC

moe wrote: post #17

threeseed wrote: post #13

Earlier quoted context omitted.

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.

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

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.

Re: Ntimed – NTPD replacement

#65

Post by atoponce » Mon, Dec 22, 2014, 2:46 PM UTC

easytiger wrote: post #46

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

Well, in the case of SSDs, every byte counts. But no, that's not my concern. My concern is installing a binary I have no intention of using. It's solid security best practices to only install what you need, and leave the rest out.

Also, I don't have a "fundamental misunderstanding of NTP". I've blogged about it quite a bit:

https://pthree.org/2013/11/05/real-life-ntp/

https://pthree.org/2013/10/13/ntp-drift-file/

https://pthree.org/2013/10/12/new-public-ntp-server/

http://transmission.xmission.com/2014/05/28/building-a-strat...

Re: Ntimed – NTPD replacement

#66

Post by mkhpalm » Mon, Dec 22, 2014, 2:48 PM UTC

Ricapar wrote: post #63

easytiger wrote: post #46

Earlier quoted context omitted.

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

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…

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.

Re: Ntimed – NTPD replacement

#67

Post by zzzcpan » Mon, Dec 22, 2014, 3:00 PM UTC

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…

I think you missed something in your calculations.

Removing 0.1% load from the machine will not result in 0.1% of energy savings, very very far from it if in any at all. And that's not even what we want to calculate. We want the difference with hypothetical alternative in a safer language, which is hard to guess, but is unlikely to be in the same order or two with your calculations.

Re: Ntimed – NTPD replacement

#68

Post by zanny » Mon, Dec 22, 2014, 3:21 PM UTC

flogic wrote: post #39

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…

Yeah. I think we've hit the point where we need to start discouraging the proliferation of C and C++ (in my opinion). It seems silly that we cling to languages from the 80's and earlier when modern languages have advanced so far.

I'm not saying a language must die because its old. Modern C++ is not bad - but you have to restrict your development into the "good" subset, and avoid the bad stuff from before. IE, use references and smart pointers rather than news and deletes.

With C, there is no alternative. It is still malloc and free, still buffer overflows and integer overflows galore, and the C language standards group is not moving to make the kinds of radical changes to modernize it the C++ one is.

Re: Ntimed – NTPD replacement

#69

Post by zanny » Mon, Dec 22, 2014, 3:26 PM UTC

panic wrote: post #44

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.

Yes, I am. I have worked on pulseaudio and gstreamer in the past (because of fundamentally broken parts I had to patch and merge upstream to get it to work) and GObject or just no type system at all is a nightmare in a huge project. I'm also contributing to frameworks 5 from KDE, and those libraries are a hell of a lot saner and they are still using Qt functions over std ones that have arisen in the last three years with better syntax, but it sure as hell beats having to spend days manually tracing all your allocations and having to write out every version of a function by hand because you can't template anything.

> separate compiler

Go has its own compiler and runtime, yeah. Rust compiles to strict native and uses LLVM. C++ uses the same compilers as C (GCC, etc). In any case, both Rust and C++ can be distributed as final binaries with no runtime dependencies besides potentially dynamically linked Rust std libs (libgreen, etc) and a C++ stdlib. Feel free to bundle those, in the same way you would have to bundle or trust the end users libc implementation.

Re: Ntimed – NTPD replacement

#70

Post by jnbiche » Mon, Dec 22, 2014, 3:41 PM UTC

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

It's a little bit sad that at -3 votes, this is the lowest voted comment I've ever had in my ~4 years on HN, lower than a number of controversial political comments.

To clarify, I'm not claiming that everyone should start using Rust. Now was I claiming that PHK is somehow unqualified for the task, far from it. I'm not even saying C is a bad language (I like C), or that people should stop using C altogether. But if you're building an security-critical application designed to be used in the future across millions of servers, and one that requires low-latency, I simply don't understand why you wouldn't strongly consider Rust, which offers strong guarantees about memory and type safety along with low latency and a very modern and complete standard library. Or Ada. Or OCaml.