[ntp:questions] NNTP server causing large jumps in time

Greg Dowd GDowd at symmetricom.com
Fri May 2 15:51:21 UTC 2008


A good example of unexpected behavior is that Dave has implemented the
notorious KoD server quench code.  As he has tweaked it, I know there
are some cases where iburst could result in KoD messages from server.  

As for ref clocks, I think iburst is a great option and I wish it were
supported.  While oscillators may still be warming up, or gps might not
be locked, the clock driver can choose to return an error but will quite
often still be FAR more accurate than a network source.  I know in some
of my boxes that have gps for primary and multiple redundant network
servers for backup can often select the network source first (especially
if the delay causes clustering that pushes them away from GPS!) and then
switch over to gps later.



  
Greg Dowd
gdowd at symmetricom dot com (antispam format)
Symmetricom, Inc.
www.symmetricom.com
"Everything should be made as simple as possible, but no simpler" Albert
Einstein
 

> -----Original Message-----
> From: questions-bounces+gdowd=symmetricom.com at lists.ntp.org 
> [mailto:questions-bounces+gdowd=symmetricom.com at lists.ntp.org]
>  On Behalf Of Kevin Oberman
> Sent: Friday, May 02, 2008 8:10 AM
> To: Ryan Malayter
> Cc: questions at lists.ntp.org
> Subject: Re: [ntp:questions] NNTP server causing large jumps in time
> 
> > Date: Fri, 2 May 2008 07:37:32 -0500
> > From: "Ryan Malayter" <malayter at gmail.com>
> > Sender: questions-bounces+oberman=es.net at lists.ntp.org
> > 
> > 
> > On Thu, May 1, 2008 at 12:25 PM, Steve Kostecke 
> <kostecke at ntp.org> wrote:
> > 
> > > You should always append iburst to your server lines.
> > 
> > Aussuming that were true, why isn't iburst the default? You 
> would then 
> > of course have to add "noiburst" to turn it off...
> 
> I suspect it is because iburst is relatively new and changing 
> defaults is something that is usually done with great 
> deliberation and only after people are REALLY sure that it is 
> the right answer, especially when it only results in an 
> improvement in startup sync and does not fix anything that 
> was failing.
> 
> I can't think of cases where 'iburst' would break things, 
> though some special cases might be better off without it, but 
> for 'normal'
> configurations using the network to chime with servers. I 
> would not use it on a reference clock, but I have not given a 
> lot of thought to what the effect of this might be.
> --
> R. Kevin Oberman, Network Engineer
> Energy Sciences Network (ESnet)
> Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
> E-mail: oberman at es.net			Phone: +1 510 486-8634
> Key fingerprint:059B 2DDF 031C 9BA3 14A4  EADA 927D EBB3 987B 3751
> 



More information about the questions mailing list