2007-02-02 08:47:11

by zhangxiliang

[permalink] [raw]
Subject: ntp

When i start the ntp service successful on server, the client must ntpdate
with the server after waiting a moment.
The moment may be 3~5 minutes, or it may be 10~15 minutes. I don't know why
it happens?

Regards
Zhang Xiliang
--------------------------------------------------
Zhang Xiliang
Development Dept.I
Nanjing Fujitsu Nanda Software Tech. Co., Ltd.(FNST)
8/F., Civil Defense Building, No.189 Guangzhou Road,
Nanjing, 210029, China
TEL: +86+25-86630566-851
COINS: 79955-851
FAX: +86+25-83317685
MAIL:[email protected]
--------------------------------------------------




2007-02-02 09:18:13

by Matti Aarnio

[permalink] [raw]
Subject: Re: ntp

On Fri, Feb 02, 2007 at 04:47:26PM +0800, zhangxiliang wrote:
> When i start the ntp service successful on server, the client must
> ntpdate with the server after waiting a moment.
> The moment may be 3~5 minutes, or it may be 10~15 minutes. I don't
> know why it happens?

The ntp server takes several external clock comparisons to know its
local running environments (hosts) clock behaviour.

Before it knows that, it has no real knowledge of what the time is,
and it won't report anything out.

In my environments I have couple local machines (usually doing
something else too) assigned as network local NTP servers, and
all other machines refer to them.


> Regards
> Zhang Xiliang
> MAIL:[email protected]

/Matti Aarnio

2007-02-04 08:00:49

by David Schwartz

[permalink] [raw]
Subject: RE: ntp


> When i start the ntp service successful on server, the client must ntpdate
> with the server after waiting a moment.
> The moment may be 3~5 minutes, or it may be 10~15 minutes. I
> don't know why
> it happens?

Two clocks cannot be synchronized instantaneously. It takes time to compare
the two clocks and adjust so that they stay in sync. A client will not
accept a date from an NTP server whose clock is not synchronized -- why
should it?

Imagine this -- you have a clock you do not trust. You ask a clock you do
trust what time it is, and it tells you it is 10:00. A bit later, I ask you
what time it is. Your clock says 10:12. Can you trust that time? Your clock
may be fast, it may be slow. You don't know. Until you check the clock you
trust a few times and confirm both clocks are flowing at the same rate, you
cannot tell the client what time it is when it asks you.

DS


2007-02-05 02:06:09

by zhangxiliang

[permalink] [raw]
Subject: Re: ntp

Hello.
When I use the ntpd service, I see if I use the client attempt to connect
the server repeat before the server is ready, the ntpd on server can not be
ready all the times.

Sometimes the waiting time maybe very long.

----- Original Message -----
From: "Matti Aarnio" <[email protected]>
To: "zhangxiliang" <[email protected]>
Cc: "Linux Kernel Mailing List" <[email protected]>
Sent: Friday, February 02, 2007 5:10 PM
Subject: Re: ntp


> On Fri, Feb 02, 2007 at 04:47:26PM +0800, zhangxiliang wrote:
>> When i start the ntp service successful on server, the client must
>> ntpdate with the server after waiting a moment.
>> The moment may be 3~5 minutes, or it may be 10~15 minutes. I don't
>> know why it happens?
>
> The ntp server takes several external clock comparisons to know its
> local running environments (hosts) clock behaviour.
>
> Before it knows that, it has no real knowledge of what the time is,
> and it won't report anything out.
>
> In my environments I have couple local machines (usually doing
> something else too) assigned as network local NTP servers, and
> all other machines refer to them.
>
>
>> Regards
>> Zhang Xiliang
>> MAIL:[email protected]
>
> /Matti Aarnio
>



2007-02-05 08:23:28

by David Schwartz

[permalink] [raw]
Subject: RE: ntp


> Hello.
> When I use the ntpd service, I see if I use the client attempt to connect
> the server repeat before the server is ready, the ntpd on server
> can not be
> ready all the times.
>
> Sometimes the waiting time maybe very long.

Sounds like NTP is the wrong tool for the job. NTP is specifically designed
to synchronize clocks with high accuracy to timing sources traceable to UTC.
It requires stable servers in order to do that. There are any number of
other time settings tools that don't try to actually synchronize clocks.

DS