Re: frequency adjusting only
- From: m.louvel@xxxxxxxxx (maxime louvel)
- Date: Mon, 21 Apr 2008 08:50:09 GMT
Thanks for your answer,
I can't have a step on the clock because that would screw up my
applications.
However if I keep the load within a certain range I should fine, don't I ?
I am synchronising one node to several public NTP servers, and the others
nodes are synchronised to the first one.
There are 2 to 24 nodes in my sub net.
Do you think that should be feasible ?
Maxime
On Sat, Apr 19, 2008 at 10:34 AM, David Woolley
<david@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
Unruh wrote:
Harlan Stenn <stenn@xxxxxxx> writes:dda529d0804160332l3bcb4e43l5623478bcd8f4fa@xxxxxxxxxxxxxx>,
In article <
m.louvel@xxxxxxxxx (maxime louvel) writes:
to
maxime> Hi, I would like to know if NTP (and particularly ntpd) is able
tomaxime> synchronise a clock, only playing with the frequency. I want
networkmaxime> avoid any step in the clock that would probably screw up my
600secmaxime> appli.
It's *possible* and it can be a really bad idea.
For most folks, only steps *backward* are a problem.
Actually, ntp does synchronize the clock by "playing with the frequency
only" unless the step size is so large (128ms by default but up to
by option) that it will step.
There are two supported settings for this limit, 128ms and 600,000ms,
but you can set other values, including infinite, with an option that
comes with severe health warnings. If you set a value of more than
500ms on systems that implement part of the clock discipline in the
kernel, you will force them not to use that mechanism, and therefore get
lower quality time.
There are also options, unfortunately also with health warnings, that
can effectively eliminate the main legitimate cause of this, which is
high asymmetric traffic loads on medium speed internet connections which
have not been traffic shaped for NTP. If you suffer large steps for
other reasons, you should fix the underlying cause. Fixing asymmetric
load can have commercial implications, as only high value ISP accounts
are likely to support the necessary traffic shaping.
(Another source of steps is lost clock ticks, but that generally only
gives the, relatively benign, positive steps.)
Systems which suffer large steps and aren't allowed to step have been
reported to hunt (in the control theory sense) rather badly.
Note, the subject is a little confusing as it could be read as meaning
that steps are allowed to remain uncorrected. That would be
unacceptable for a protocol where every node is both client and server.
That would be like if you had to drive 30 miles and insisted that you
drove at 30 mph, but you were delayed by a traffic jam, and still
declared the journey complete after exactly one hour.
_______________________________________________
questions mailing list
questions@xxxxxxxxxxxxx
https://lists.ntp.org/mailman/listinfo/questions
--
Maxime Louvel
0044 7964 5555 80
43 Allen road
Whitemore reans
WV60AW Wolverhampton
United Kingdom
.
- Follow-Ups:
- Re: frequency adjusting only
- From: Danny Mayer
- Re: frequency adjusting only
- From: Harlan Stenn
- Re: frequency adjusting only
- References:
- Re: frequency adjusting only
- From: Harlan Stenn
- Re: frequency adjusting only
- From: Unruh
- Re: frequency adjusting only
- From: David Woolley
- Re: frequency adjusting only
- Prev by Date: Re: frequency adjusting only
- Next by Date: comp.protocols.time.ntp charter
- Previous by thread: Re: frequency adjusting only
- Next by thread: Re: frequency adjusting only
- Index(es):
Relevant Pages
|