Using Go for NTPsec

[Eric S. Raymond]

Hal Murray <halmurray at sonic.net>:
> >> 1. packet tx happening right after tx timestamp for server response
> 
> > A) Mitigate window 1 by turning off GC before it and back on after.
> 
> Things get complicated.  Consider a multi threaded server.  If you have 
> several busy server threads, can they keep the GC off 100% of the time?  
> (Condider a DDoS attack.)

We don't have a multithreaded server yet.  Worst case we have two
threads, and only one can ever reach the critical region in question.
Don't borrow trouble! :-)

If we go to using threads more heavily, the idiomaric Go way to handle
this problem would be to have a queue that does only the code in
window 1.  When you write to the request queue, it would stop GC, do
time-critical magic, restart GC, and ship the result on the output
queue.

I'm not worries about a DDoS. I don't think the protocol machine gives
a hostile client or server any way to force hitting that window.

> If you are going to claim the GC doesn't take long and doesn't happen often, 
> maybe you should just put a big comment in the code and not do anything.  
> Better would be a design note collecting all the info.

I've said several times that I think the most likely outcome is that
no special action is needed!

But you've asked me to justify the position that Go GC would not be
not a performance problem, which is a *completely reasonable* thing
to ask; I made the same demand of myself when I started thinking about
a Go port.

Thus the detaled discussion of mitigation strategy.

> There is a close-to-RFC to handle this area.  "Interleave" is the buzzword.  I 
> haven't studied it.  The idea is to grab a transmit time stamp, then tweak the 
> protocol a bit so you can send that on the next packet.

Daniel discovered it was broken and removed it from the protcol machine.

> >> 2. serial NMEA data timestamps
> 
> > B) Mitigate window 2 by taking timestamps before and after sample read,
> > asking the Go runtime if a GC has occurred in that interval, and throwing out
> > the sample if it has. This tactic might slow convergence times minutely but
> > should not affect overall sync accuracy.
> 
> There isn't a convenient "before".  You want to do something like readline, 
> and that's going to wait a while.  You don't care if it does a GC while you 
> are waiting.  So you will have to do something like read the first character, 
> grab the before stamp, read the second character, grab the after time stamp, 
> grab the rest of the line.  Then work out the begin/end of line timing by 
> counting characters and doing the arithmetic with the baud rate.
> 
> But is that worth the effort?  Are there any serial devices with timing good 
> enough to notice?

Good question. Certainly a Macx-1 gets nowhere near that granularity, not with .0125s
of inherent jitter due to USB poll interval; that swamps 600usec by more than two
orders of magnitude.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>