Hacker News Reader

Hacker News

Comment by zzzcpan | Hacker News Reader

Parent Full thread

zzzcpan

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

View on HN

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.

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

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

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.

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.

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.

Reply on news.ycombinator.com