Hal Murray <hmur...@megapathdsl.net>:
>
> e...@thyrsus.com said:
> >> My big concern is that nobody else seems to be testing it. There may be
> >> dragons that I haven't poked.
> > Understood. Unfortunately I myself can't be much help here - my outside
> > view
> > of NTP is still weak, I have only limited ability to recognize what normal
> > operation should look like or spot deviations from it. Gary or Achim or
> > Matt
> > would be better for that end of things.
>
> I'm not worried about subtle problems.(*) I'm interested in the big picture.
>
> Is there too much crap in the log file? Does the reach column in ntpq -p
> look
> reasonable? ...
Ah, well, that I can handle.
I'm past due to refresh the test farm software, anyway.
> The other half of the big picture is setting up certificates.
Yeah, that's the part I'm not looking forward to documenting.
> *) There is actually one interesting point that authentication makes more
> interesting. On receive, we get a time stamp when the packet arrives. We
> can
> take all day to inspect the packet and run authentication code. On transmit,
> we grab the time and put it in the packet. All the delays between then and
> when the packet hits the wire are contributing to a misleading time stamp.
> Authentication code is on that path. The same thing happens on both client
> and server. If they are similar CPUs, the offsets should cancel. If not,
> ...
> I think we can measure this by comparing IPv4 and IPv6 with NTS on one.
Let me take a different tack: can we move the aut computation off path?
--
<a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>
My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.
_______________________________________________
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
