> 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? -- Rich Wales / ri...@richw.org / ri...@stanford.edu Wikipedia: http://en.wikipedia.org/wiki/User:Richwales Facebook: http://www.facebook.com/richwales _______________________________________________ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
