Using Go for NTPsec

[Hal Murray]

Eric said:
> Talk to me about what you think the effect of very occasional stop-the-world
> pauses of 600 microseconds or less would be on sync accuracy. By "very
> occasionally" let's say once every ten minutes or so, that being what I think
> is a *very* pessimistic estimate of GC frequency for a program with NTP's
> memory-usage pattern.

Could you please say more?  How did you get 600 microseconds?  What 
assumptions were you making?

> What I want to understand - and have others understand - is whether pauses of
> that size and frequency would mess with sync accuracy enough that heroic
> measures are required to avoid them.  What kind of distortion would they
> introduce in comparison with other components of the error budget? 

I expect that a pause every 10 minutes would be hard to notice.  But I don't 
think that's the major problem.

The real cost of using a GC is that we have to keep thinking about what it 
might do, or if the code we want to write might change the assumptions used to 
conclude that an occasional GC was OK.

If we get a sample that is off by enough to be interesting, is that because 
the network was busy or the GC did its thing?

Suppose Eric got up on the other side of the bed one morning, and I proposed 
using some new system that had a GC and waved my hands and claimed that it 
wouldn't be a problem.  I wouldn't be at all surprised if Eric claimed it was 
ugly, not appropriate, and we should find something better.

I'm assuming the goal is more than just to convert our current code base to a 
safe language.  We also need to get the structure and environment right.  An 
environment with a GC seems like a bad start.

--------

You haven't commented about my Rust vs Go question.

A friend commented that he might use Go over Rust because it would be easier 
for others to pick up.

I'm learning Rust, or trying to.  I find it not-easy, but picking up new 
languages is not one of my strong points.  The type-checking is really picky.  
I like it!  I can usually understand the error messages but sometimes it takes 
me a while to figure out how to do something the way it likes.  I think things 
will get much easier after I've written enough code so that I have samples of 
whatever I need that I can copy.

I have an echo server off the ground far enough to run some tests.  No unsafe 
code yet.  It feels good, but it's only 66 lines.

It doesn't do recv time stamps.  As far as I can tell, there isn't a clean way 
to do that in Rust.

--------

Crazy thought dept...

Assuming we want to us Go, can we split things up such that the timing 
critical code runs in separate processes without GC?

I know how to split out the server side of ntpd.

Suppose we come up with an API for refclocks.  Would that, or something 
similar also work for network servers?

I think the timing critical code would be small enough that we could write it 
in C and inspect it carefully.  That may not be valid if we include the crypto 
stuff.

Converting that that sort of code to Rust seems reasonable.


-- 
These are my opinions.  I hate spam.