Hello! Harlan Stenn wrote:
As I said in my reply, I don't believe ntpdate will sync in this case either, and I think this patch is an amazingly bad idea.
On the time server machine, I am currently using ntpdate to acquire remotely the time offset of my unsync'd systems. nptdate works for this application (calculating and printing the time offset). And yes, you are also right, it refuses to sync. :-)
Example: # /usr/sbin/ntpdate -q 10.0.0.100 server 10.0.0.100, stratum 16, offset -0.727935, delay 0.03511 21 Mar 09:54:53 ntpdate[26279]: no server suitable for synchronization found
I'm open to hearing any reason why somebody would want to sync to an unsync'd clock, and I'll be impressed and amazed if this topic is worth discussing in the WG.
My use case is not to sync but only to get the time offset (in order to calculate the skew). As ntpdate will be retired soon from the official distribution, I'd suggest that maybe sntp could behave in the same way as ntpdate does: acquire the time offset (including uttering complaints) but refuse to sync (command line options -r or -a?).
Cheers Daniel _______________________________________________ questions mailing list [email protected] https://lists.ntp.isc.org/mailman/listinfo/questions
