Andrew Hisgen wrote: > Darren.Reed at Sun.COM wrote: > >> Brian Utterback wrote: >> >> >>> Here is what I propose in the V4 code: >>> >>> In V4, ntpdate is no longer used. Instead, the NTP has a new mode >>> that is used only on the first synchronization. It goes into a >>> super fast mode that gets an offset to within a second in about >>> 5 seconds instead of the 5 minutes previously needed. > > I'm not understanding the previous sentence. I wonder if > you could help me to understand it with the following example. > Let us say that the ntp client is 18 minutes behind the servers > (by servers here I mean the ntp time sources). How long will > the client take to adjust to being close to the servers time? > You seem to be saying that it will take only five seconds. > And that after this five seconds, the clocks are now different > by at most a second (this is my reading of what the phrase > "within a second").
Sounds like you understood perfectly, you have it exactly right. With the new "iburst" option, NTP will send a volley of requests fairly quickly, getting a fair approximation of the offset within a few seconds. This is exactly as ntpdate behaves now. > > I've deliberately chosen 18 minutes because of your use of > a 20 minute figure below, but, if I am hearing you right, > I did not need to do that; it could have been a very large > number of minutes different on the client? Right. The current V3 ntpdate and xntpd must have the client within 34 years to correctly determine the offset. The V4 code extends this to 68 years. But other than that, the first correction may be any magnitude. Subsequent correction must be less than 20 minutes. > > I'm not following the larger purpose of this first synchronization. > If you are trying to avoid dramatically jumping the clock, I don't > think you are acheiving that. You seem to be just effectively > replacing the traditional need/use of an initial ntpdate command > before the ntpdemon starts? Of course if the client's and server's clocks are radically different then you can not avoid a dramatic clock jump unless you are willing to wait months or more for the clock to get into line. That 20 minute correction would take 27 days to correct at the maximum slew rate. The problem has been that ntpdate and xntpd programs have different configuration methods and security models. This meant that trying to keep them in sync has been error prone and with the different securrity models, possible insecure. With the current set up, the ntpdate program must set the clock once before it completes otherwise if the clock is more than 20 minutes off then the xntpd program will exit on it's first sync. This is the source of the problem being discussed here, namely that the ntpdate is waiting so long, but there isn't anyway to get around it cleanly. > > thanks, > Andy Hisgen > >>> It will then >>> correct this offset, regardless of the magnitude, just as ntpdate >>> does now. It will do this just once, afterward imposing a 20 minute >>> maximum offset. >>> >>> >> >> ... >> >> (This isn't OpenSolaris specific....) >> >> Something that I've noticed the NTP daemon cannot do is >> deal with clocks that just won't align. The worst culprit that >> I have run into is running anything inside of vmware workstation, >> where the best solution I've found is to run ntpdate every 10 >> or so minutes. Is there any hope that NTPv4 will be better? >> >> Darren >> >> _______________________________________________ >> smf-discuss mailing list >> smf-discuss at opensolaris.org > >
