Using Go for NTPsec

[Hal Murray]

> Right.  But the way to get there is certainly *not* to try to design ahead
> while you're still thinking in a language like C where concurrent programming
> is difficult and error-prone.

This is not a hard problem.  There is nothing tricky.

> Once you get used to being able to program in Go's implementation of
> communicating sequential processes you'll gave much better tools for doing
> concurrency. 

You have a new toy.  The only tool needed is a simple lock.

There are N server threads.  They are each in a loop that does a recvfrom(), 
fills in the reply, then a sendto().

Filling in the reply needs to access some data that is in globals in the 
current code.  That needs a simple lock.  If the packet is authenticated, 
accessing the key needs another lock.


>> You can't put it on an ouput queue.  Handing it to the kernel it is part of 
>> the time critical region.
> I meant output *channel*.  With a goroutine spinning on the end of it. 

Either I wasn't clear or you were really focused on using your new toy.

The case we are trying to protect from the GC is the transmit side.  The 
critical chunk of code starts with putting a time stamp into the packet, 
optionally adds the authentication, then sends it.  At that point, the packet 
is gone.  There is nothing to put on a queue or into a channel.

------------

> Do you know what our actual bottlenecks are? Have you [rofioled them?

Have I used Eric's favorite profiling tool?  Probably not.

But I think I have a pretty good idea of where the CPU cycles are going.  Who 
do you think wrote all the timing hacks in the attic?

I have a multi-threaded echo server and enough other hacks to drive it and 
collect data.  It has a knob to inject spin between the recvfrom and sendto.  
The idea is to simulate the NTP computations and/or crypto.  Do you want 
graphs?

I have similar hacks to collect data on running NTP servers.


I've also been working with Dick Sites' KUTrace.


-- 
These are my opinions.  I hate spam.