Rich, Correct; the interleaved modes, both symmetric and broadcast, are in the development version now. They do not use 1588 hardware, although conceivably they could with appropriate NICs. They use what I call drivestamps, which are captured very close to the driver interrupt time. In configurations here interleaved modes whack anywhere from 15 microseconds to 400 microseconds off the output queuing, buffering and transmission delay. There is a chapter about it in my new book in progress. It has more analysis and performance measurements. If somebody wants to review and comment, I would be happy to provide a copy, but I don't want to broadcast it, as it is copyrighted.
Dave Rich Wales wrote: >>You misunderstand the usage of the xleave option which is still >>experimental. It requires (currently) IEEE-1588 hardware to work >>and it needs to be set up to send additional time-delay information >>down the same path as the ntp packet. >> >> > >I'm confused now, because the description of interleaved symmetric mode >in http://www.eecis.udel.edu/~mills/onwire.html clearly claims that the >NTP reference implementation does handle interleaved mode via software >timestamps. Quoting from the introduction of the above page: > > "The interleaved modes described in this section have been > implemented and tested in the NTP reference implementation. > In its present form only software timestamps (softstamps) are > used, with the advantage that the actual transmit timestamp is > captured upon return from the I/O routine and more accurately > represents the on-wire hardware timestamp (hardstamp). Future > plans include using driver timestamps or NIC timestamps as the > opportunity arises." > >Thus, I assumed that if I had two servers, running ntp-dev and peering >with each other, with the "xleave" option specified on each server for >its association with the other server, they would use the two-step >"interleaved symmetric mode" protocol described in the above web page >(with software-generated time stamps) -- and that doing this should do >a decent job of correcting automatically for asymmetry in the network >connection, without needing to fudge the asymmetry explicitly -- and >that the end result would be good as long as I wasn't expecting to get >super-accurate, sub-microsecond sync (for which I admittedly would >need special network cards with hardware timestamp capabilities). > >Am I mistaken here? > > > _______________________________________________ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
