f



NTP, no external time source, peering "Undisciplined Local Clocks" ?

Say I have a network with no access to the internet, and I have no
external time reference (no GPS or atomic or whatever clock available).
I am using the NTP reference implementation ntpd on FreeBSD.

The network is composed of 3 hosts: A, B and C.

I know I can tell NTP to use the local clock as a time reference, what
is called an "Undisciplined Local Clock" in the NTP documentation.

Say I don't know if a clock is better than the other, so by configuring
B and C to use A as server I risk to have a not so good time if A is 
unreliable.

Can I configure A,B,C to peer with each other in a meshed fashion, so
to have each clock influenced by all the others? From what I read I 
should use the following configuration file on each host:

========== /etc/ntp.conf ======
server 127.127.1.0
peer hostA
peer hostB
peer hostC
==================

would it work? Is it the best way to obtain the "best" time assuming
I don't know if a clock is better than another?

thanks
marco
_______________________________________________
questions mailing list
questions@lists.ntp.isc.org
https://lists.ntp.isc.org/mailman/listinfo/questions

0
mmolteni (2)
10/18/2005 2:19:11 PM
comp.protocols.time.ntp 4895 articles. 2 followers. Post Follow

10 Replies
2113 Views

Similar Articles

[PageSpeed] 14

"Marco Molteni" <mmolteni@cisco.com> wrote in message 
news:200510181619.11961.mmolteni@cisco.com...

> I know I can tell NTP to use the local clock as a time reference, what
> is called an "Undisciplined Local Clock" in the NTP documentation.
>
> Say I don't know if a clock is better than the other, so by configuring
> B and C to use A as server I risk to have a not so good time if A is
> unreliable.
>
> Can I configure A,B,C to peer with each other in a meshed fashion, so
> to have each clock influenced by all the others? From what I read I
> should use the following configuration file on each host:
>
> ========== /etc/ntp.conf ======
> server 127.127.1.0
> peer hostA
> peer hostB
> peer hostC
> ==================
>
> would it work? Is it the best way to obtain the "best" time assuming
> I don't know if a clock is better than another?

    IMO, NTP is not appropriate for this type of configuration.

    DS


0
David
10/19/2005 10:52:56 AM
"Marco Molteni" <mmolteni@cisco.com> wrote in message
news:200510181619.11961.mmolteni@cisco.com...
[...]
> I know I can tell NTP to use the local clock as a time reference, what
> is called an "Undisciplined Local Clock" in the NTP documentation.
>
> Say I don't know if a clock is better than the other, so by configuring
> B and C to use A as server I risk to have a not so good time if A is
> unreliable.
>
> Can I configure A,B,C to peer with each other in a meshed fashion, so
> to have each clock influenced by all the others?

Even if two clocks more or less agree on the time and the third one is
an outlyer, there would be no reason to believe that the two agreeing
ones are more right.

In order for the local clock to work as a reference clock, NTP has
to _believe_ it. And it will effectively believe that it's exactly
accurate, with zero offset and zero jitter. By definition. So NTP has
no basis to judge the "quality" of the clocks on, anymore than you do.

Groetjes,
Maarten Wiltink


0
Maarten
10/19/2005 11:15:03 AM
At 4:19 PM +0200 2005-10-18, Marco Molteni wrote:

>  Can I configure A,B,C to peer with each other in a meshed fashion, so
>  to have each clock influenced by all the others?

	Okay, let's analyze this a bit.  You've got three guys on a 
desert island, and they each have wristwatches.  But no one knows 
whose watch is more accurate.  What time is it and how do you choose?

	The answer is that you either choose arbitrarily, or you can't 
choose.  At least, not with the NTP algorithms.


	The concept of NTP is to have an external source of "The One True 
Time", and to always try to work to get your clock to more closely 
agree with that.  There are plenty of algorithms for doing that, but 
everything operates on the fundamental assumption that everyone has 
the same goal, that of always trying to move closer to "The One True 
Time".

	When you violate that most basic assumption, everything else goes 
out the window.


	I don't think that NTP is the right solution here.

-- 
Brad Knowles, <brad@stop.mail-abuse.org>

"Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety."

     -- Benjamin Franklin (1706-1790), reply of the Pennsylvania
     Assembly to the Governor, November 11, 1755

   SAGE member since 1995.  See <http://www.sage.org/> for more info.
_______________________________________________
questions mailing list
questions@lists.ntp.isc.org
https://lists.ntp.isc.org/mailman/listinfo/questions

0
brad
10/19/2005 11:36:49 AM
On Wed, 19 Oct 2005 03:52:56 -0700, "David Schwartz" <davids@webmaster.com>
wrote:

>
>"Marco Molteni" <mmolteni@cisco.com> wrote in message 
>news:200510181619.11961.mmolteni@cisco.com...
>
>> I know I can tell NTP to use the local clock as a time reference, what
>> is called an "Undisciplined Local Clock" in the NTP documentation.
>>
>> Say I don't know if a clock is better than the other, so by configuring
>> B and C to use A as server I risk to have a not so good time if A is
>> unreliable.
>>
>> Can I configure A,B,C to peer with each other in a meshed fashion, so
>> to have each clock influenced by all the others? From what I read I
>> should use the following configuration file on each host:
>>
>> ========== /etc/ntp.conf ======
>> server 127.127.1.0
>> peer hostA
>> peer hostB
>> peer hostC
>> ==================
>>
>> would it work? Is it the best way to obtain the "best" time assuming
>> I don't know if a clock is better than another?
>
>    IMO, NTP is not appropriate for this type of configuration.

But the timed(8) time server daemon might be just what you want.  It'll slow
some clocks and speed up others to keep the whole flock in synch.
0
Marc
10/19/2005 12:11:48 PM
On Tue, 18 Oct 2005 14:19:11 GMT, mmolteni@cisco.com (Marco Molteni)
wrote for the entire planet to see:

>Say I don't know if a clock is better than the other, so by configuring
>B and C to use A as server I risk to have a not so good time if A is 
>unreliable.
>
>Can I configure A,B,C to peer with each other in a meshed fashion, so
>to have each clock influenced by all the others? 

The general feeling on this ng is that this is not a good application
for NTP.

I would go further, and say it is a poor design using any type of
software.  Sure, you may get some weird approximation of the average
clock errors around your network, but it will still drift, by an
unknown amount.  

Three PCs, all of which don't know the time, can't really help each
other find it.

- Eric

0
Eric
10/19/2005 5:46:03 PM
Marco Molteni wrote:

>Say I have a network with no access to the internet, and I have no
>external time reference (no GPS or atomic or whatever clock available).
>I am using the NTP reference implementation ntpd on FreeBSD.
>
>The network is composed of 3 hosts: A, B and C.
>
>I know I can tell NTP to use the local clock as a time reference, what
>is called an "Undisciplined Local Clock" in the NTP documentation.
>
>Say I don't know if a clock is better than the other, so by configuring
>B and C to use A as server I risk to have a not so good time if A is 
>unreliable.
>
>Can I configure A,B,C to peer with each other in a meshed fashion, so
>to have each clock influenced by all the others? From what I read I 
>should use the following configuration file on each host:
>
>========== /etc/ntp.conf ======
>server 127.127.1.0
>peer hostA
>peer hostB
>peer hostC
>==================
>
>would it work? Is it the best way to obtain the "best" time assuming
>I don't know if a clock is better than another?
>
>thanks
>marco
>_______________________________________________
>questions mailing list
>questions@lists.ntp.isc.org
>https://lists.ntp.isc.org/mailman/listinfo/questions
>
>  
>
If you care about the CORRECT time, this configuration is an almost 
certain loser!  There is a White Paper available from Sun Microsystems 
that claims this configuration will synchronize all the systems to the 
same time.  See http://www.sun.com/blueprints.  The paper is entitled 
"Using NTP to Control and Synchronize System Clocks and can be 
downloaded in three parts.   It's by David Deeths and Glenn Brunette.  
You'll find a brief reference to the synchronization of an isolated 
network of peers on page 7 of part one.  I have not tried this 
configuration and cannot attest that it actually works.

To find the best clock, set all three to the correct time using your 
cellular phone if available or your wristwatch if not.   The cell phone 
display shows only hours and minutes but the rollover of the minute 
should be accurate to within a few microseconds.  If you have fast 
reflexes you should be able to set the time to within one second.   Let 
the three systems run for a few days and check the clocks.  The one 
closest to the correct time should have the best clock.  Typical 
computer clocks can gain or lose two to four minutes per month so don't 
expect too much.

If you want the correct time, invest in a GPS receiver.   I've heard of 
suitable receivers available in the $80-$90 US range.   I bought a 
Motorola receiver specifically designed for timing applications for $200 
US.  I keep one of my Sun Ultra 10 workstations synchronized to within 
ten microseconds or better with it.  This receiver is just a bare 
circuit board, a wall-wart, and an antenna.  If you wish, you can pay 
thousands of dollars for one in a fancy case with built-in NTP server 
but it's not necessary.
0
Richard
10/19/2005 7:22:18 PM
Eric,

As confirmed by experiment, having each client average all the others is 
not a good idea. The ensemble tends to do a random walk and display very 
poor statility. Better to pick one of them and let it time the rest. 
However, folks have tended to extend this idea to provide a multiple 
backup capability. This is a bad idea, as evil timing loops can form 
that take a long time to count to infinity.

There is a new wrinkle designed for isolated configurations with 
multiple backup requirements. It is called orphan mode and works best 
with broadcast/multicast networks or networks with multiple 
symmetric-mode networks. The networks self-organize, elect a leader and 
pecking order depending on the particular failure topology. It's been 
tested here in the ntp-dev version, but should still be considered 
experimental. See the documentation on the authentication options and 
miscellaneous commands pages in the online documentation.

Dave

Eric wrote:
> On Tue, 18 Oct 2005 14:19:11 GMT, mmolteni@cisco.com (Marco Molteni)
> wrote for the entire planet to see:
> 
> 
>>Say I don't know if a clock is better than the other, so by configuring
>>B and C to use A as server I risk to have a not so good time if A is 
>>unreliable.
>>
>>Can I configure A,B,C to peer with each other in a meshed fashion, so
>>to have each clock influenced by all the others? 
> 
> 
> The general feeling on this ng is that this is not a good application
> for NTP.
> 
> I would go further, and say it is a poor design using any type of
> software.  Sure, you may get some weird approximation of the average
> clock errors around your network, but it will still drift, by an
> unknown amount.  
> 
> Three PCs, all of which don't know the time, can't really help each
> other find it.
> 
> - Eric
> 
0
David
10/19/2005 8:52:09 PM
Dave,

one-time mode may help Eric?

Pedro


Em Qua 19 Out 2005 18:52, David L. Mills escreveu:
> Eric,
>
> As confirmed by experiment, having each client average all the others is
> not a good idea. The ensemble tends to do a random walk and display very
> poor statility. Better to pick one of them and let it time the rest.
> However, folks have tended to extend this idea to provide a multiple
> backup capability. This is a bad idea, as evil timing loops can form
> that take a long time to count to infinity.
>
> There is a new wrinkle designed for isolated configurations with
> multiple backup requirements. It is called orphan mode and works best
> with broadcast/multicast networks or networks with multiple
> symmetric-mode networks. The networks self-organize, elect a leader and
> pecking order depending on the particular failure topology. It's been
> tested here in the ntp-dev version, but should still be considered
> experimental. See the documentation on the authentication options and
> miscellaneous commands pages in the online documentation.
>
> Dave
>
> Eric wrote:
> > On Tue, 18 Oct 2005 14:19:11 GMT, mmolteni@cisco.com (Marco Molteni)
> >
> > wrote for the entire planet to see:
> >>Say I don't know if a clock is better than the other, so by configuring
> >>B and C to use A as server I risk to have a not so good time if A is
> >>unreliable.
> >>
> >>Can I configure A,B,C to peer with each other in a meshed fashion, so
> >>to have each clock influenced by all the others?
> >
> > The general feeling on this ng is that this is not a good application
> > for NTP.
> >
> > I would go further, and say it is a poor design using any type of
> > software.  Sure, you may get some weird approximation of the average
> > clock errors around your network, but it will still drift, by an
> > unknown amount.
> >
> > Three PCs, all of which don't know the time, can't really help each
> > other find it.
> >
> > - Eric
>
> _______________________________________________
> questions mailing list
> questions@lists.ntp.isc.org
> https://lists.ntp.isc.org/mailman/listinfo/questions

=2D-=20
Atenciosamente, Regards,
Pedro Rodrigues Torres J=FAnior
RNP / PoP-PR
Tel: 55 41 3361-3343
_______________________________________________
questions mailing list
questions@lists.ntp.isc.org
https://lists.ntp.isc.org/mailman/listinfo/questions

0
torres
10/19/2005 9:43:49 PM
On 2005-10-19, Richard B. Gilbert <rgilbert88@comcast.net> wrote:

> If you want the correct time, invest in a GPS receiver.   I've heard of 
> suitable receivers available in the $80-$90 US range. 

The Garmin GPS18-LVC is one. Mine was ~$83 including shipping from
Provantage.

On a "good day" I see a peer summary like:

ident            cnt     mean     rms      max     delay     dist     disp
==========================================================================
127.127.20.0    5243    0.000    0.004    0.015    0.000    0.270    0.247

-- 
Steve Kostecke <kostecke@ntp.isc.org>
NTP Public Services Project - http://ntp.isc.org/
0
Steve
10/20/2005 3:13:20 AM
Steve Kostecke wrote:

> 
> On a "good day" I see a peer summary like:
> 
> ident            cnt     mean     rms      max     delay     dist     disp
> ==========================================================================
> 127.127.20.0    5243    0.000    0.004    0.015    0.000    0.270    0.247
> 

Hi Steve--I notice you're running with a 16 second poll interval (minpoll 4).
I have a 1ghz machine with 64 second poll and yesterday's data shows:

        ident     cnt     mean     rms      max     delay     dist     disp
==========================================================================
127.127.20.0    1339    0.001    0.002    0.012    0.000    0.000    0.000

That was for a linux 2.4.20 ppskit host. A freebsd 4.7 266Mhz host with the
same refclock/poll interval (via a fanout box) shows:

        ident     cnt     mean     rms      max     delay     dist     disp
==========================================================================
127.127.20.0    1340    0.000    0.003    0.011    0.000    0.990    0.967

I'm not sure what to make of these figures. Any pll wizards care to comment?

By the way, the script is in ntp-dev/scripts/stats/peer.awk if the reader
would like to check their own system.

.../Steven
0
rtxo
10/20/2005 4:01:57 AM
Reply: