Ntimed – NTPD replacement • Hacker News Board

Re: Ntimed – NTPD replacement

#71

Post by easytiger » Mon, Dec 22, 2014, 3:54 PM UTC

atoponce wrote: post #65

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…

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/ htt…

> It's solid security best practices to only install what you need, and leave the rest out.

You are installing only what you need. And running it in the mode you suggested, client only, will lead to no philosophically different a state than a all new client that does the same thing. Once you set it running as a privileged user it cannot be modified by other users. It will have been tested in your environment and signed off by your infosec team if that isn't you. How is that different from any other piece of software that has options you should never use?

Are you saying if your users use git that the 'bisect' command should be removed because they never need to use it?

Re: Ntimed – NTPD replacement

#72

Post by easytiger » Mon, Dec 22, 2014, 3:56 PM UTC

swinglock wrote: post #26

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…

Debian has a chrony package as well, another alternative ntpd.

That simply won't do for OP as he seems to want solely client only mode implementation of NTP. chrony supports both. He seems to think the authors of these daemons don't have his best interests at heart by adding functionality he doesn't want personally yet many other people will use.

Re: Ntimed – NTPD replacement

#73

Post by easytiger » Mon, Dec 22, 2014, 3:57 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…

Run it in client only mode and it won't

Re: Ntimed – NTPD replacement

#74

Post by moe » Mon, Dec 22, 2014, 4:04 PM UTC

mcgoo wrote: post #64

moe wrote: post #17

Earlier quoted context omitted.

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.

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?

Re: Ntimed – NTPD replacement

#75

Post by easytiger » Mon, Dec 22, 2014, 4:04 PM UTC

jnbiche wrote: post #56

jnbiche wrote: post #40

Earlier quoted context omitted.

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.

> Go is also a better alternative to C in many instances.

Go isn't in the same ballpark nor do the authors (venerable as they are) seem to have considered that many people need consistent power over their run time execution when microseconds matter. stop the world is not a viable memory management trade off. Also managing memory in c++ these days is pretty "easy".

I've leived for years with people spending hundreds of man hours a year trying to get around issues caused by STW pauses in high throughput java applications. Makes no sense.

Re: Ntimed – NTPD replacement

#76

Post by lazyjones » Mon, Dec 22, 2014, 4:34 PM UTC

phkamp wrote: post #54

lazyjones wrote: post #51

Earlier quoted context omitted.

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

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

284K, which is a whopping 0.04% of available memory. I don't see how this increases CO2 output though.

> Things add up

To a still very insignificant number, dwarfed by the beef consumption of the people reading this.

I'd say there are better arguments in favour of using dated languages than this.

Re: Ntimed – NTPD replacement

#77

Post by phkamp » Mon, Dec 22, 2014, 5:35 PM UTC

easytiger wrote: post #72

swinglock wrote: post #26

Earlier quoted context omitted.

Debian has a chrony package as well, another alternative ntpd.

That simply won't do for OP as he seems to want solely client only mode implementation of NTP. chrony supports both. He seems to think the authors of these daemons don't have his best interests at heart by adding functionality he doesn't want personally yet many other people will use.

I fully agree with him that client-only mode deserves its own program, given that less than 1% of all computers ever need to be NTP servers.

Re: Ntimed – NTPD replacement

#78

Post by flogic » Mon, Dec 22, 2014, 6:37 PM UTC

zanny wrote: post #68

flogic wrote: post #39

Earlier quoted context omitted.

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

I'm not going to pass myself off as a C++ expert. That said, I think it's very telling that we haven't had an unsuccessful pwn2own yet.

Re: Ntimed – NTPD replacement

#79

Post by asveikau » Mon, Dec 22, 2014, 7:23 PM UTC

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.

Rust seems interesting, though when I read about it I often think "sounds good, but why not just use C or C++?" These are, after all, already working well for a lot of people, and working just about everywhere. And you don't have issues that come with an experimental language: like on day x GC is a good idea, and on day x + 1 reference counted pointers are the way to go.

The benefits range from overstated [bounds checking is a thing, but amongst experienced practitioners using modern, safe styles and conventions, lack of memory safety is not really the huge issue people say it is] to sometimes irrelevant [I read that the concurrency model aims to eliminate the possibility of race conditions entirely - who cares? In many domains races are a fact of life, benign, or totally manageable, so it appears to solve the wrong problem].

As for Go, I do acknowledge the background of its creators [venerable, as another commenter said], but most stuff I see written by "rank and file" members of that community is very clearly written by people who mostly deal in higher-level languages.

Re: Ntimed – NTPD replacement

#80

Post by phkamp » Mon, Dec 22, 2014, 7:25 PM UTC

lazyjones wrote: post #76

phkamp wrote: post #54

Earlier quoted context omitted.

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…

> Second, have you checked the memory footprint of NTPD ? "machine resources" is more than CPU cycles. 284K, which is a whopping 0.04% of available memory. I don't see how this increases CO2 output though. > Things add up To a still very insignificant number, dwarfed by the beef consumption of the people reading this. I'd say there are better arguments in favour of using dated languages than this.

I can't change how much beef people eat.

I can change how their computers synchronize time.