Terje Mathisen wrote: > Andy Helten wrote: > >> Unruh wrote: >> >>> uh, ntpdate is severely depricated, and ntpd -g is what is supposed to be >>> used. If ntpd -g fails it is a bug. >>> >>> >> Then it is a bug because, as previously mentioned, no command line >> argument or tinker can disable this behavior. I suppose the solution is >> to skip the CLOSETIME check in clocktime() when '-g' is specified. >> > > Andy, I agree totally: > > With no remote reference clocks, only local hardware, said hardware has > to skip the sanity checks during that initial -g adjustment. > > Andy, you should go on the ntp.org site and register this as a bug! > > Terje >
Before creating a bug report I searched the database for "CLOSETIME" and found a bug report had already been opened. The status is "NEW", which seemed to imply someone following this email discussion beat me to the punch. However, the existing bug report was opened in April of 2005. There is some back-and-forth discussion between the developers (including Dave Mills), but clearly there was no consensus on how it needs to be fixed and there has been no discussion since August 2005. There were some patches submitted that either did not address the exact problem we are discussing here or the patches were never accepted. Not sure what the protocol is for this situation, but it appears the original bug report needs a bump: https://support.ntp.org/bugs/show_bug.cgi?id=417 Andy _______________________________________________ questions mailing list [email protected] https://lists.ntp.org/mailman/listinfo/questions
