Re: NNTP server causing large jumps in time

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@xxxxxxxxxxxxx
[mailto:questions-bounces+gdowd=symmetricom.com@xxxxxxxxxxxxx]
On Behalf Of Kevin Oberman
Sent: Friday, May 02, 2008 8:10 AM
To: Ryan Malayter
Cc: questions@xxxxxxxxxxxxx
Subject: Re: [ntp:questions] NNTP server causing large jumps in time

Date: Fri, 2 May 2008 07:37:32 -0500
From: "Ryan Malayter" <malayter@xxxxxxxxx>
Sender: questions-bounces+oberman=es.net@xxxxxxxxxxxxx


On Thu, May 1, 2008 at 12:25 PM, Steve Kostecke
<kostecke@xxxxxxx> 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@xxxxxx Phone: +1 510 486-8634
Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751

.

Relevant Pages
Loading