Hal Murray <halmur...@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>
_______________________________________________
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
