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

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?