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? ... The other half of the big picture is setting up certificates. --------- *) 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. -- These are my opinions. I hate spam. _______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
