Time until synchronized

>>> In article <39EA5C210755754BB6F997B693820C2201B44C5E@esealmw121.eemea.ericsson.se>, [email]anton.a.persson@ericsson.com[/email] (Anton Persson A) writes:

Anton> We have, however, in the /etc/ntp.conf file explicitly stated that
Anton> the daemon should communicate using NTP v3. What this means is that
Anton> ntpd says, to to the server it is synching with, that it uses NTP v3
Anton> (even though it is capable of v4.) I have no idea how this affects
Anton> the different state machines running inside the ntpd, just that the
Anton> packet it sends out on the network state v3 instead of the default
Anton> v4. The reasons for this is requirements from a legacy project which
Anton> we are communicating with..

You should not need to do this.

When two NTP procecess 'communicate', they each offer the 'highest' version
they know how to speak and then continue the association at the lower
version.

Something like:

v4: I can talk ntpv4
v3: I can talk ntpv3
v4: I'm talking to you at ntpv3

--
Harlan Stenn <stenn@ntp.org>
[url]http://ntpforum.isc.org[/url] - be a member!

Hi,

(Steve Kosteckes reply follows further down)

I am not expecting anything, I first asked if an explicit requirement
found in RFC 4330 (SNTPv4) is also, implicitly, valid for the RFC
defining
the NTPv3 standard (RFC 1305). The requirement in RFC 4330 is as
follows:

A client SHOULD increase the poll interval using exponential
backoff as performance permits and especially if the server does
not respond within a reasonable time.

As you should understand, this is not an explicit requirement found in
RFC 1305,
but I would like to know if it is an implicit requirement, or if it is
implemented
anyway in ntp v4.2.4 (as distributed in Red Hat Enterprise Linux). I.e.
should
I expect ntp v4.2.4, as distributed in RHEL, to use this exponential
backoff
when I forcefully configure it to use NTPv3 and the connection to the
NTP server
is lost? And, if it does indeed implement this even when using V3, how
long should
it take for NTP to increase the poll interval from 64 to 128 seconds?

Some people are asking me why we are forcing it to use NTP v3, the
reasons for
this is that our test-environment is also using ntp v4.2.4 from SUSE,
but the
target environment is using a NTPv3 implementation (I am not aware of
exactly
which implementation this is, but it is not important for a test where
the
server has stopped responding). We don't have access to the target
environment
in such a way that we can always run tests against it, so therefore we
force
ntp 4.2.4 to use v3 explicitly.

Best regards, Anton Persson

-----Original Message-----
From: questions-bounces+anton.a.persson=ericsson.com@lists.ntp.org
[mailto:questions-bounces+anton.a.persson=ericsson.com@lists.ntp.org] On
Behalf Of Steve Kostecke
Sent: den 18 juni 2008 18:03
To: [email]questions@lists.ntp.org[/email]
Subject: Re: poll interval - Clarification! -
RFCcompliancequestion

On 2008-06-17, Anton Persson A <anton.a.persson@ericsson.com> wrote:
[color=blue]
> The poll interval is 64 to 1024, seconds. ntpd starts up, locks on
> target, stays synchronized for a while, then we pull the plug.[/color]

What are you trying to prove by "pulling the plug"?
[color=blue]
> The poll interval is at this time still 64 seconds, how long should it[/color]
[color=blue]
> take to step up the interval to 128 seconds for a completely failed
> link?[/color]

Why would you expect the poll interval to change if ntpd is not
receiving replies to polls?

--
Steve Kostecke <kostecke@ntp.org>
NTP Public Services Project - [url]http://support.ntp.org/[/url]

John,

I don't know if Linux has modified the tree, but there are lots of
copyrighted files, including many of the refclock drivers and options
stuff. A list of all known and attributed contributors is on the
copytright.html page. Some of these go back to 1988.

Dave

John Ackermann N8UR wrote:[color=blue]
> Unruh said the following on 06/15/2008 11:35 AM:
>
>[color=green]
>>Yes, it is pedantry, since the copyright is automatic and does not need to
>>be asserted. Ie, that notice is infomational, not a legal requirement.
>>It simply informs the reader as to who actually owns the copyright. What is
>>not mere pedantry is where or not this claim is actually true. Many people
>>have contributed to ntpd, and unless they all transfered copyright to David
>>Mills, then the claim that he owns the copyright is really false. They all
>>do (David has copyright interest in all of the works since the other
>>people's work is derivative of his work, but others have copyright interest
>>as well.) To keep things perfectly clean, David shoule ask anyone who
>>contributes to transfer their copyright to him.[/color]
>
>
> While the notice is not mandatory, it does have legal value -- in
> particular, it negates a defense of innocent infringement. And, to
> claim the international protection of the UCC treaty I referred to in my
> other message, you do need to include the notice.
>
> Your point about whether the copyright notice is accurate is
> interesting. I wonder if it would even be possible at this point to
> determine who all the contributors are!
>
> I thought that Linux used the CREDITS file as a list of copyright
> holders, but I just looked at some source and that doesn't appear to be
> the case -- instead, each source file has its own copyright notice in
> the name of one or more people, with the COPYING file not listing any
> copyright owners at all. I guess that has the effect of putting the
> whole kernel tree under the GPL, but the resulting object file(s) as a
> collective work of all the contributors.
>
> I just looked at the ntp 4.2.0 source (the only tree I have handy at the
> moment) and the random source files I looked at do not have any
> copyright notice at all, so the Linux model doesn't appear to be in place.
>
> John[/color]

Steve,

The poll interval backs off if the configured server has not been heard
for ten intervals, then the interval doubles for each poll until
reaching 1024 s. This is designed to reduce the network load if nobody
is home.

Dave

Steve Kostecke wrote:
[color=blue]
> On 2008-06-17, Anton Persson A <anton.a.persson@ericsson.com> wrote:
>
>[color=green]
>>The poll interval is 64 to 1024, seconds. ntpd starts up, locks on
>>target, stays synchronized for a while, then we pull the plug.[/color]
>
>
> What are you trying to prove by "pulling the plug"?
>
>[color=green]
>>The poll interval is at this time still 64 seconds, how long should it
>>take to step up the interval to 128 seconds for a completely failed
>>link?[/color]
>
>
> Why would you expect the poll interval to change if ntpd is not
> receiving replies to polls?
>[/color]

Harlan,

Not quite. The NTPv4 server replies with the same version as received in
an NTP packet. The configuration version option applies only to packets
that are sent unsolicited. Other than this, the version number plays no
part in packet processing.

Dave

Harlan Stenn wrote:
[color=blue][color=green][color=darkred]
>>>>In article <39EA5C210755754BB6F997B693820C2201B44C5E@esealmw121.eemea.ericsson.se>, [email]anton.a.persson@ericsson.com[/email] (Anton Persson A) writes:[/color][/color]
>
>
> Anton> We have, however, in the /etc/ntp.conf file explicitly stated that
> Anton> the daemon should communicate using NTP v3. What this means is that
> Anton> ntpd says, to to the server it is synching with, that it uses NTP v3
> Anton> (even though it is capable of v4.) I have no idea how this affects
> Anton> the different state machines running inside the ntpd, just that the
> Anton> packet it sends out on the network state v3 instead of the default
> Anton> v4. The reasons for this is requirements from a legacy project which
> Anton> we are communicating with..
>
> You should not need to do this.
>
> When two NTP procecess 'communicate', they each offer the 'highest' version
> they know how to speak and then continue the association at the lower
> version.
>
> Something like:
>
> v4: I can talk ntpv4
> v3: I can talk ntpv3
> v4: I'm talking to you at ntpv3
>[/color]

Anton Persson A wrote:
[color=blue]
>
> A client SHOULD increase the poll interval using exponential
> backoff as performance permits and especially if the server does
> not respond within a reasonable time.
>
> As you should understand, this is not an explicit requirement found in
> RFC 1305,[/color]

In the case of servers that are replying, the NTP specification provides
a lot of detail about exactly what "as performance permits" means, and
does require an exponential backoff whilst the quality of the server is
such that it is of benefit.

Steve Kostecke <kostecke@ntp.org> writes:
[color=blue]
>On 2008-06-17, Anton Persson A <anton.a.persson@ericsson.com> wrote:[/color]
[color=blue][color=green]
>> The poll interval is 64 to 1024, seconds. ntpd starts up, locks on
>> target, stays synchronized for a while, then we pull the plug.[/color][/color]
[color=blue]
>What are you trying to prove by "pulling the plug"?[/color]
[color=blue][color=green]
>> The poll interval is at this time still 64 seconds, how long should it
>> take to step up the interval to 128 seconds for a completely failed
>> link?[/color][/color]
[color=blue]
>Why would you expect the poll interval to change if ntpd is not
>receiving replies to polls?[/color]

NTP v4states that you should increase the polll interval if no replies are
received. The problem was that some decreased the poll interval, swamping
the net.

David Woolley wrote:[color=blue]
> Anton Persson A wrote:
>[color=green]
>> we are using the ntp v3 protocol, as defined in RFC1305, however
>> I have a question running through my head when I consider the poll
>> interval.[/color]
>
> You are going to have limited success getting help on that specification
> here as it is considered obsolete, even though the version 4
> specification is still only, officially, a draft. As such people are
> going to give you the answers for version 4 or have to cast their minds
> back several years.[/color]

I don't think that RFC 1305 specified a backoff requirement. In the
current NTP v4 draft, we require a backoff if you receive a KOD with a
RATE kiss code but it does not specify a specific amount.

Danny