On Sun, Jan 08, 2017 at 06:02:36PM -0500, Eric S. Raymond wrote: > Hal Murray <hmur...@megapathdsl.net>: > > We don't care about the timing in most of the code. The only critical > > section is the chunk between grabbing the time and sending the packet. > > That > > chunk is likely to involve crypto. > > > > We could fix that with another packet. The idea is that you get a time > > stamp > > from the kernel on the transmit side. Then you have to send another packet > > to get that time stamp to the other end. > > > > Maybe we should add that to the NTPv5 list. > > No, I'd much rather put in a GC lockout on the critical region than > complicate the protocol. > > That said, I continue to admire your cut right to the heart of the issue. > ntpd spends enough time in I/O waits that I do not think latency spikes > will otherwise induce any problems above measurement noise.
The extra packet will improve the precision. It will eliminate one source of jitter. And I guess there will be people who would want to use it, but now have to use PTP. They probably have the right hardware for it to be really useful. But I think in the general case, the jitter caused by the network will be higher than then what this would win. But then I have no idea if someone actually tried something like this over the internet with standard hardware and what the effect of it is. Kurt _______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
