4 ms·

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

by zzzcpan 12y ago

StillBored 12y ago
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.
- jnbiche 12y ago
  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).
  - xorcist 12y ago
    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.
  - jnbiche 12y ago
    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.
phkamp 12y ago
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.
- lazyjones 12y ago
  > 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.
  - phkamp 12y ago
    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.
    - lazyjones 12y ago
      > 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.
      - phkamp 12y ago

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

by zzzcpan 12y ago

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.

jnbiche 12y ago
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).
- xorcist 12y ago
  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.
- jnbiche 12y ago
  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.

phkamp 12y ago

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.

lazyjones 12y ago
> 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.
- phkamp 12y ago
  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.
  - lazyjones 12y ago
    > 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.
    - phkamp 12y ago