Replacing C

[Eric S. Raymond]

Hal Murray <hmurray at megapathdsl.net>:
> 
> [Transmit path]
> > No, I'd much rather put in a GC lockout on the critical region than
> > complicate the protocol. 
> 
> That works if the environment has a GC lockout.  Is that a column on your 
> features list?

Not explicitly, but there is no way I would *ever* try using a
language with GC for soft-realtime work (even soft realtime as
comparatively squishy as NTP) unless it had that capability.  I
wasn't even a bit surprised Pike and his crew put in that switch; I
share traditions with them that would demand it.

> > ntpd spends enough time in I/O waits that I do not think latency spikes will
> > otherwise induce any problems above measurement noise. 
> 
> I don't think the I/O waits are important.  We need to work correctly when 
> the server is overloaded.

Serious question: how often does this actually happen? I want to get
a feel for scale.

> The key idea is that the server contributes 2 time stamps, the difference is 
> how long the packet spent on the server, either waiting to get processed 
> and/or actually getting processed say because the crypto takes a lot of CPU 
> cycles.
> 
> We should measure the time from grabbing the time stamp to sending the 
> packet.  That might include some crypto.  We might get better results by 
> adjusting the time stamp to compensate for that.

Good idea.  I'd do it something like this:

1. Every time we ship a packet, take timestamps at the beginning and end of the
critical region.

2. On the next send, adjust the timerstamp by the average of all previous ones.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>