5 ms·

That sounds like you're implying that safety has no value, the only "overhead" worth considering is CPU cycles (what about the programmer's time/effort/sanity?)

That sounds like you're implying that safety has no value, the only "overhead" worth considering is CPU cycles (what about the programmer's time/effort/sanity?), and that abstractions have negative value. I don't think that's how you're supposed to software.

zzzcpan 12y ago
Yeah. Especially considering that CPU overhead has very little value for time syncing program.
- 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
threeseed 12y ago
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.
- moe 12y ago
  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 complexity, space, overhead. In this case abstractions mean you can probably write the whole thing in under 2 kloc, get memory safety for free, and base it on a network stack that other people actually use and debug independently. It is a tightly focused, specific utility that shouldn't see too many changes after a certain point. Umm. Yea. Right. Tell that to the ntpd guys with their 100kloc codebase...
  - mcgoo 12y ago
    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.
    - moe 12y ago
      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?
nwmcsween 12y ago
Safety has value it just doesn't imply overhead. Abstractions are a negative, they make reasoning burdensome.
- cbd1984 12y ago
  Abstractions are what make it possible to reason about complex systems. Being able to ignore parts of your codebase is the only way to make changes to it once it gets beyond a trivial size. The whole of the Unix philosophy is enforcing this policy of strong abstractions by making each part of a complex overall system its own binary, such that they can only communicate using the file I/O abstraction, possibly via pipes. C was therefore designed for a system which promotes abstractions.
  - deleted 12y ago
    [deleted]
    - cbd1984 12y ago
      Even if your comment both made sense and was factually accurate, it wouldn't have much relevance to the kind of C programming I'm talking about: For example, mmap(2) isn't defined in the C standard but in POSIX, but it's universal in the Unix and Unix-like OS world to the extent programs can safely rely on it. Standards are good and useful things, but they're only fully written down in retrospect.
    - tedunangst 12y ago
      Section 7.19.3.
      - function_seven 12y ago
        I'm getting 7.21.3, reading here[1], but that's the draft spec for C11. I couldn't find the official one anyhere. [1] http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf

zzzcpan 12y ago

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

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

threeseed 12y ago

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.

moe 12y ago
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 complexity, space, overhead. In this case abstractions mean you can probably write the whole thing in under 2 kloc, get memory safety for free, and base it on a network stack that other people actually use and debug independently. It is a tightly focused, specific utility that shouldn't see too many changes after a certain point. Umm. Yea. Right. Tell that to the ntpd guys with their 100kloc codebase...
- mcgoo 12y ago
  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.
  - moe 12y ago
    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?

nwmcsween 12y ago

Safety has value it just doesn't imply overhead. Abstractions are a negative, they make reasoning burdensome.

cbd1984 12y ago
Abstractions are what make it possible to reason about complex systems. Being able to ignore parts of your codebase is the only way to make changes to it once it gets beyond a trivial size. The whole of the Unix philosophy is enforcing this policy of strong abstractions by making each part of a complex overall system its own binary, such that they can only communicate using the file I/O abstraction, possibly via pipes. C was therefore designed for a system which promotes abstractions.
- deleted 12y ago
  [deleted]
  - cbd1984 12y ago
    Even if your comment both made sense and was factually accurate, it wouldn't have much relevance to the kind of C programming I'm talking about: For example, mmap(2) isn't defined in the C standard but in POSIX, but it's universal in the Unix and Unix-like OS world to the extent programs can safely rely on it. Standards are good and useful things, but they're only fully written down in retrospect.
  - tedunangst 12y ago
    Section 7.19.3.
    - function_seven 12y ago
      I'm getting 7.21.3, reading here[1], but that's the draft spec for C11. I couldn't find the official one anyhere. [1] http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf