Using Go for NTPsec

[Dan Drown]

Quoting Achim Gratz via devel <devel at ntpsec.org>:
:
> I tend to organize timer triggered code in a way that any computations
> that take a long or indeterminate time happen after the time-critical
> section that uses either very short computations or precomputed values
> from the last period.  That assumes that the resulting lag until the
> next timer invocation can be taken into account (which should usually be
> possible).  So if things get organized like that, as long as whatever GC
> does is done until the next trigger would not matter at all.

Let's talk a bit about what time critical sections are currently in  
the code.  I think that will help drive the decision about the impact  
of garbage collection.

I haven't looked at ntpsec's codebase lately, so some of this might be  
out of date.  Please feel free to correct any mistakes or omissions.

Time critical code:

1. packet tx happening right after tx timestamp for server response
2. serial NMEA data timestamps

Non time critical code:

1. packet rx timestamp (assumption: SO_TIMESTAMPNS or alike is being used)
2. packet tx happening right after tx timestamp for client request  
(assumption: SO_TIMESTAMPNS or alike is being used)
3. receiving SHM data
4. receiving PPS data
5. calculating/updating local clock offset/frequency

The time critical code can tolerate some level of delay (~hundreds of  
microseconds), as things like packet tx can be delayed for a multitude  
of kernel and hardware reasons.  The good news is both of the time  
critical code paths are somewhat predictable and if we can manually  
schedule GC, we can avoid scheduling it during those times.

The non timing critical code can be delayed tens of milliseconds  
without an impact to timing quality.