4 ms·

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 any

by 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?

by moe 12y ago

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?