Robert, I've had this discussion literally hundreds of times over the last 25 years. Somebody tells me they absolutely must have residual error less than x millisconds guaranteed not more than y minutes after startup. But this pits the Principle of Least Astonishment against the constraints of physics. There is a tradeoff between the precision in estimating the intrinsic frequency of the oscillator and the time to make and refine that estimate.
When first starting ntpd without the drift file, by default the state machine takes fifteen minutes to directly compute the initial frequency estimate within about 1 PPM, then enables the native clock discipline algorithm. You can change this using the "tinker stepout" command to shorten the initial time; however, the estimation error will be worse and could well cause the succeeding offsets to exceed 10 ms until the loop settles down. The clock discipline algorithm takes far longer than five minutes to refine the time and frequency estimate within 10 ms confidence. At the lowest poll interval of 16 s, the discipline crosses zero in about fifteen minutes, but the frequency convergence can take four times as long. So, even if you shorten the stepout threshold to five minutes and rely on the discipline to complete the initial convergence, you are still left with some uncertainty that your 10-ms constraints might be violated. Notwithstanding the constraints you are faced with, the following are your ONLY choices: 1. Pay more money for the oscillator and/or select the crystal within a tolerance of 10 PPM or less. That's what Digital did for the Alpha. I've never seen an Alpha with more than 5 PPM frequency error. 2. Provide a fine oscillator frequency adjustment (VXO) and calibrate during initial test. 3. Measure the oscillator frequency error during manufacturing and save this in the BIOS flash where the operating system can find it. 4. Set the stepout interval to five minutes and accept what errors remain once the state machine has enabled the discipline. 5. Don't do anything and require a hot spare is always available with a burn in of several hours. Dave Robert Wachinger wrote: > Maarten Wiltink <[EMAIL PROTECTED]> wrote: > >>"Robert Wachinger" <[EMAIL PROTECTED]> wrote in message >>news:[EMAIL PROTECTED] >>[...] >> >>>We have here the requirement to have a replaced board (a fresh one >>>from the factory, where a correct content of the drift file is >>>unknown) up after 5 minutes in a cluster, which also means, that >>>its time does not stray more than 10ms (within the cluster). >>> >>>Any tips? >>>We tried here to "play" with minpoll, burst, initial drift files >>>(value 0). > > >>Iburst would start you with a low offset. But that has really >>absolutely nothing to do with intrinsic frequency error. > > >>Can you run (NTP on) the board outside the cluster? Your problem is >>that you don't know the correct drift value. It seems simple then: >>you should find out. > > > That would mean additional manual handling (and is therefore costful). > > >>I'm not sure if limiting maxpoll is guaranteed to keep your offset >>low the way running ntpdate often would; frankly I doubt it. > > > So no idea, to reduce the time until a drift value is stable enough. > > >>Doesn't the cluster allow you to add nodes in standby mode? > > > Hm, nice idea. Maybe that could work ... > > Regards, Robert > _______________________________________________ questions mailing list [email protected] https://lists.ntp.isc.org/mailman/listinfo/questions
