Using Go for NTPsec

[Hal Murray]

>> 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.)

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.

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.


>> 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?

-- 
These are my opinions.  I hate spam.