I'm trying to sync the time on 2 Windows XP computers that are not on
the internet and never will be. For testing purposes, they need to
have the same time. The time does not need to be accurate. What's the
simplest way to sync these computers?

I've done a lot of searching, but can't seem to find much about
computers not attached to the internet.

I've tried net time \\computer_ip /set /yes, but I get an access
denied error.

Thanks in advance.

Richard B. Gilbert <rgilbert88@comcast.net> wrote:
> The easiest thing to do if you can site an antenna where it will have an 
>   unobstructed view of the sky, is to purchase a "hardware reference 
> clock".  The cheapest goes for about $100 US.  It's called a GPS18-LVC 
> if memory serves me.  If my memory fails me I'm sure someone will be 
> delighted to point it out!  ;-)

A reference clock is completely unnecessary for what he wants to do,
let alone a view of the sky.

One computer can be synced to the other, and the objective has been
achieved.

I am not sure if Windows XP can act as an NTP time server without install
of ntpd.  It can act as a client with no problem.
Maybe ntpd has to be installed on one PC (with LOCAL as the reference
clock) and then the other can either use the w32time standard NTP service
or ntpd can be installed on the second PC as well.

Richard B. Gilbert <rgilbert88@comcast.net> wrote:
> Rob wrote:
>> Richard B. Gilbert <rgilbert88@comcast.net> wrote:
>>> The easiest thing to do if you can site an antenna where it will have an 
>>>   unobstructed view of the sky, is to purchase a "hardware reference 
>>> clock".  The cheapest goes for about $100 US.  It's called a GPS18-LVC 
>>> if memory serves me.  If my memory fails me I'm sure someone will be 
>>> delighted to point it out!  ;-)
>> 
>> A reference clock is completely unnecessary for what he wants to do,
>> let alone a view of the sky.
>> 
>> One computer can be synced to the other, and the objective has been
>> achieved.
>> 
>> I am not sure if Windows XP can act as an NTP time server without install
>> of ntpd.  It can act as a client with no problem.
>> Maybe ntpd has to be installed on one PC (with LOCAL as the reference
>> clock) and then the other can either use the w32time standard NTP service
>> or ntpd can be installed on the second PC as well.
>
> Have you ever tried synching two computers, neither of which has a 
> stable and accurate source of time?  It usually looks something like one 
> drunken driver trying to follow another!

Of course you should not configure them to follow another in both directions.
When the second computer follows the first, there is nothing instable
or wrong going on.  You can even pick the computer that has the most
stable clock before configuring them.

> PCs, in particular, tend to suffer from clock drift.  If computers did 
> have stable and accurate clocks, what would we need NTP for?

Irrelevant.  The poster said the time did not need to be accurate.
He only requires the time to be the same on both computers.  There is
nothing that a GPS receiver will add to the system to make this easier
than without it.  But of course it adds complexity and requirements.

On 2010-03-19, cnoyes2 <cnoyes2@gmail.com> wrote:

> I'm trying to sync the time on 2 Windows XP computers that are not on
> the internet and never will be. For testing purposes, they need to
> have the same time. The time does not need to be accurate.

You're not concerned about whether or not the clocks are stable or
monotonic?

> What's the simplest way to sync these computers?

That depends on your error budget.

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

On 2010-03-19, cnoyes2 <cnoyes2@gmail.com> wrote:

> I'm trying to sync the time on 2 Windows XP computers that are not on
> the internet and never will be. For testing purposes, they need to
> have the same time. The time does not need to be accurate. What's the
> simplest way to sync these computers?
>
> I've done a lot of searching, but can't seem to find much about
> computers not attached to the internet.

http://support.microsoft.com/kb/314054
How to configure an authoritative time server in Windows XP

"Configuring Windows Time service to use an internal hardware clock
To configure the Windows Time service to use an internal hardware clock,
you can change the announce flag on the authoritative time server.
Changing the announce flag forces the computer to announce itself as a
reliable time source and to use the built-in complementary metal oxide
semiconductor (CMOS) clock. To configure the Windows Time service to use
an internal hardware clock, follow these steps."

http://support.microsoft.com/kb/314090
Using the NET TIME Command to Synchronize Windows XP Workstations

http://support.microsoft.com/kb/307897/EN-US/
How to synchronize the time with the Windows Time service in Windows XP

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

On Mar 19, 18:21=A0UTC, a xs4all user wrote:
> Of course you should not configure them to follow another in both directi=
ons.
> When the second computer follows the first, there is nothing instable
> or wrong going on. =A0You can even pick the computer that has the most
> stable clock before configuring them.

That's tricky without internet or other access to a stable frequency
source.  The machines in question do not and never will have access to
the internet.

> He only requires the time to be the same on both computers. =A0There is
> nothing that a GPS receiver will add to the system to make this easier
> than without it. =A0But of course it adds complexity and requirements.

There's one thing -- irrelevant if w32 time sync is close enough, but
ntpd has a 500ppm limit on frequency correction.  Depending on the
number of machines (two here) and each machine's normal frequency
error, it may be necessary to get the source machine's frequency
closer to correct to bring it in the range the other can correct.
This is unlikely to be a problem with a couple of machines each within
125ppm, for example, but get unlucky with a few hundred ppm positive
on one and negative on the other, or add more machines to the brew,
and your chances of having problems using an errant frequency standard
(the source machine's uncorrected clock) go up.

Cheers,
Dave Hart

Group,

With due humbleness and respect to both 'cnoyes2' (the original author) and Steve Kosteke---I would think he (cnoyes2) isn't concerned with whether the clocks are monotonic (whatever that is).

I understand and fully agree that unmanaged clocks, which are not 
sync'd to an authoritative time-source will drift, and it can get 
horrible and other bad things can happen.  Got that.

What seems to get lost, and admittedly not explained very well---hence 
my attempt here.... is that there are many situations these days where 
folks are developing, working, troubleshooting real-world problems in 
environments big and small that are deliberately isolated (and rightfully so)---and 
just don't have the luxury of an authoritative time-source  --  but just want time to 'work' and be sync'd.  They are not going to get an authoritative time-source.  They are not knowledgeable/experienced 
with ntp (raises my own hand high here).  They need meaningful technical advice (ideally from this community), broken down into layman's 
terms, on how to establish 'the best that can be possible' in a private 
environment knowing it will never get to have an authoritative 
time-source.

In other words---how can we broaden folks knowledge of ntp, in enjoyable ways, tell them first what they CAN do and solve their ntp problems along the way?

R,
-Joe Wulf
 Senior IA Engineer/ISSE
 ProSync Technology Group, LLC




----- Original Message ----
> From: Steve Kostecke <kostecke@ntp.org>
> To: questions@lists.ntp.org
> Sent: Fri, March 19, 2010 2:56:14 PM
> Subject: Re: [ntp:questions] Quick sync between two computers not connected to the internet
> 
> > On 2010-03-19, cnoyes2 <
> > href="mailto:cnoyes2@gmail.com">cnoyes2@gmail.com> wrote:
> >
> > I'm trying to sync the time on 2 Windows XP computers that are not on
> > the internet and never will be. For testing purposes, they need to
> > have the same time. The time does not need to be accurate.
>
> You're not concerned about whether or not the clocks are stable or monotonic?
>
> Steve Kostecke

-------- Original Message --------
Subject: Re: Quick sync between two computers not connected to the internet
Date: Sat, 20 Mar 2010 13:06:38 -0400

Please don't sure off your mastery of time by posting from the future!

From: Richard B. Gilbert <rgilbert88@comcast.net>
Reply-To: rgilbert88@comcast.net
Newsgroups: comp.protocols.time.ntp
References: 
<5c674c2c-1bfc-48c9-88a2-816a32c92dd2@19g2000yqu.googlegroups.com>

c

cnoyes2 wrote:

> I've tried net time \\computer_ip /set /yes, but I get an access
> denied error.
> 

Do you have local administrator rights?

David Woolley wrote:
> -------- Original Message --------
> Subject: Re: Quick sync between two computers not connected to the internet
> Date: Sat, 20 Mar 2010 13:06:38 -0400
> 
> Please don't sure off your mastery of time by posting from the future!
> 
> From: Richard B. Gilbert <rgilbert88@comcast.net>
> Reply-To: rgilbert88@comcast.net
> Newsgroups: comp.protocols.time.ntp
> References: 
> <5c674c2c-1bfc-48c9-88a2-816a32c92dd2@19g2000yqu.googlegroups.com>
> 
> c

Sorry about that and thanks for pointing it out.  Someday I'll figure 
out how I managed to do that!

On 2010-03-19, Dave Hart <davehart@gmail.com> wrote:
> On Mar 19, 18:21?UTC, a xs4all user wrote:
>> Of course you should not configure them to follow another in both directions.
>> When the second computer follows the first, there is nothing instable
>> or wrong going on. ?You can even pick the computer that has the most
>> stable clock before configuring them.
>
> That's tricky without internet or other access to a stable frequency
> source.  The machines in question do not and never will have access to
> the internet.

So just pick one randomly, or because you like its colour
..


>
>> He only requires the time to be the same on both computers. ?There is
>> nothing that a GPS receiver will add to the system to make this easier
>> than without it. ?But of course it adds complexity and requirements.
>
> There's one thing -- irrelevant if w32 time sync is close enough, but
> ntpd has a 500ppm limit on frequency correction.  Depending on the
> number of machines (two here) and each machine's normal frequency
> error, it may be necessary to get the source machine's frequency
> closer to correct to bring it in the range the other can correct.
> This is unlikely to be a problem with a couple of machines each within
> 125ppm, for example, but get unlucky with a few hundred ppm positive
> on one and negative on the other, or add more machines to the brew,
> and your chances of having problems using an errant frequency standard
> (the source machine's uncorrected clock) go up.

That 500PPM was chosen as a sufficiently large value that no standard
machine should come close. For a while the linux kernel time
standardizing routine really screwed up and you would have machines
which were 100-200 PPM out. But that has now I believe been fixed. Ie,
this should not be a problem.

"cnoyes2" <cnoyes2@gmail.com> wrote in message 
news:5c674c2c-1bfc-48c9-88a2-816a32c92dd2@19g2000yqu.googlegroups.com...
> I'm trying to sync the time on 2 Windows XP computers that are not on
> the internet and never will be. For testing purposes, they need to
> have the same time. The time does not need to be accurate. What's the
> simplest way to sync these computers?
>
> I've done a lot of searching, but can't seem to find much about
> computers not attached to the internet.
>
> I've tried net time \\computer_ip /set /yes, but I get an access
> denied error.
>
> Thanks in advance.

Just some suggestions....  Install NTP on both computers:

  http://www.satsignal.eu/ntp/setup.html
  http://www.meinberg.de/english/sw/ntp.htm

Choose one as a reference, and be sure that the ntp.conf includes the 
"local-clock" option.  So on the master ntp.conf:

______________________________
server  127.127.1.0  # local clock
______________________________


Set the other to sync from the first, and tie it as closely as possible by 
using the minpoll and maxpoll parameters.  In ntp.conf on the slave, use 
something like:

______________________________
server  <master-ip>  iburst  minpoll 4 maxpoll 4
______________________________


See if that works well enough for you.  There is something called orphan 
mode which is designed for circumstances like yours, but I haven't used it 
myself.

Cheers,
David 

cnoyes2 wrote:
> I'm trying to sync the time on 2 Windows XP computers that are not on
> the internet and never will be. For testing purposes, they need to
> have the same time. The time does not need to be accurate. What's the
> simplest way to sync these computers?
> 
> I've done a lot of searching, but can't seem to find much about
> computers not attached to the internet.
> 
> I've tried net time \\computer_ip /set /yes, but I get an access
> denied error.
> 
> Thanks in advance.

How close do the two clocks have to be?  It's fairly easy to get two 
computers to agree within five or ten seconds with no special equipment 
or software required.  If you need to be within five or ten milliseconds 
it starts getting difficult and possibly expensive.  If you need to be 
within five or ten microseconds it can still be done but it will take 
some fairly expensive equipment.

The easiest thing to do if you can site an antenna where it will have an 
  unobstructed view of the sky, is to purchase a "hardware reference 
clock".  The cheapest goes for about $100 US.  It's called a GPS18-LVC 
if memory serves me.  If my memory fails me I'm sure someone will be 
delighted to point it out!  ;-)

The GPS18-LVC and other similar devices, get time from the NAVSTAR (GPS) 
satellites.  The antenna is generally smaller than a hockey puck.  I 
have mine on top of a "Leaf Guard" rain gutter.  They have a Pulse Per 
Second (PPS) output.  One edge of the pulse is generally within 50 
nanoseconds of the true time.  There is also an RS232C serial output 
that tells you which second the pulse is marking.

NTPD has drivers for a number of different devices.  In addition to GPS 
satellites there are VLF and HF broadcasts provided by the National 
Institute of Standards and Technology (NIST) in the US.  Other countries 
also provide radio time signals.

Rob wrote:
> Richard B. Gilbert <rgilbert88@comcast.net> wrote:
>> The easiest thing to do if you can site an antenna where it will have an 
>>   unobstructed view of the sky, is to purchase a "hardware reference 
>> clock".  The cheapest goes for about $100 US.  It's called a GPS18-LVC 
>> if memory serves me.  If my memory fails me I'm sure someone will be 
>> delighted to point it out!  ;-)
> 
> A reference clock is completely unnecessary for what he wants to do,
> let alone a view of the sky.
> 
> One computer can be synced to the other, and the objective has been
> achieved.
> 
> I am not sure if Windows XP can act as an NTP time server without install
> of ntpd.  It can act as a client with no problem.
> Maybe ntpd has to be installed on one PC (with LOCAL as the reference
> clock) and then the other can either use the w32time standard NTP service
> or ntpd can be installed on the second PC as well.

Have you ever tried synching two computers, neither of which has a 
stable and accurate source of time?  It usually looks something like one 
drunken driver trying to follow another!

PCs, in particular, tend to suffer from clock drift.  If computers did 
have stable and accurate clocks, what would we need NTP for?

Has anybody noticed the first word in cnoyes2's subject line:
"Quick" ?
NTP can take hours to settle, and is better suited to configurations
where
the computers run 24*7.

How quickly do you need to achieve sync? How often are the PCs
switched off
and cold-started?

Paul

"pc" <Paul.Croome@softwareag.com> wrote in message 
news:9d912d64-b725-46a2-bc21-a91070e0c695@z4g2000yqa.googlegroups.com...
> Has anybody noticed the first word in cnoyes2's subject line:
> "Quick" ?
> NTP can take hours to settle, and is better suited to configurations
> where
> the computers run 24*7.
>
> How quickly do you need to achieve sync? How often are the PCs
> switched off
> and cold-started?
>
> Paul

If sync within 128msec is good enough, then NTP could be said to be 
"instant".  cnoyes2 didn't specific an accuracy, I believe.

Cheers,
David 

pc wrote:
> Has anybody noticed the first word in cnoyes2's subject line:
> "Quick" ?
> NTP can take hours to settle, and is better suited to configurations
> where
> the computers run 24*7.
> 
> How quickly do you need to achieve sync? How often are the PCs
> switched off
> and cold-started?

For me using "iburst" for server line and "ntpd -q" before
starting ntpd will get within 10ms or so. With just two servers
I'd expect one having to be chosen as in some way better and have
the second synchronise to that before starting ntpd. Here using
"ntpd -q" twice, prior to starting ntpd, seems to always get
within a couple of ms. Assuming a good and low drift value it
will converge from that point. I've occasionally seen problems
with just two systems both set as peers when drifts are in
opposing direction when I've seen a large divergence before
settling down so I'd avoid that configuration (possibly more
recent ntpd is better).


David

David Lord wrote:

> 
> For me using "iburst" for server line and "ntpd -q" before
> starting ntpd will get within 10ms or so. With just two servers

Not with standard parameters.  Standard parameters will only get you 
within 128ms, unless the error was more than 128ms to start with.

pc wrote:
> Has anybody noticed the first word in cnoyes2's subject line:
> "Quick" ?

Yes.  That's why I tried to address the permissions problem.

David Woolley wrote:
> David Lord wrote:
> 
>>
>> For me using "iburst" for server line and "ntpd -q" before
>> starting ntpd will get within 10ms or so. With just two servers
> 
> Not with standard parameters.  Standard parameters will only get you 
> within 128ms, unless the error was more than 128ms to start with.

sudo ntpq -p
serv1  192.168.....   2 u   53  128  377 0.535  21.891  2.791
serv2  .MSFa.         2 u    8  128  377 0.359  20.134  1.709
serv3  192.168.....   2 u  125  128  377 0.666  19.719  1.385

sudo /etc/rc.d/ntpd stop

sudo ntpd -q
ntpd: time slew +0.008954s
sudo ntpd -q
ntpd: time slew +0.005993s
sudo ntpd -q
ntpd: time slew +0.000084s

sudo /etc/rc.d/ntpd start

ntpq -p
serv1  192.168.....   2 u - 64   1 1.678 0.569 0.219
serv2  .MSFa.         1 u - 64   1 1.565 0.545 0.180
serv3  192.168.....   2 u - 64   1 1.723 0.899 0.678

ntpq -p
serv1  192.168.....   2 u - 64 177 0.457 1.272 1.774
serv2  .MSFa.         1 u - 64 177 0.310 1.262 1.668
serv3  192.168.....   2 u - 64 177 1.378 2.153 1.656

Drift file was out at start and offset increasing


David

On Mar 19, 2010, at 1:19 PM, Joe Wulf wrote:
> Group,
> 
> With due humbleness and respect to both 'cnoyes2' (the original author) and Steve Kosteke---I would think he (cnoyes2) isn't concerned with whether the clocks are monotonic (whatever that is).

It means whether the clock values always increase.

Some hardware clocks are sufficiently broken that they might "jump backwards" which can cause logic errors in programs which assume that time always increases; good platforms check for and try to avoid using broken clocks.  It's also hard to imagine a circumstance where someone would care about whether a clock is sync'ed to something else *and* not care about whether the clock is working at all.

> I understand and fully agree that unmanaged clocks, which are not 
> sync'd to an authoritative time-source will drift, and it can get 
> horrible and other bad things can happen.  Got that.
> 
> What seems to get lost, and admittedly not explained very well---hence 
> my attempt here.... is that there are many situations these days where 
> folks are developing, working, troubleshooting real-world problems in 
> environments big and small that are deliberately isolated (and rightfully so)---and 
> just don't have the luxury of an authoritative time-source  --  but just want time to 'work' and be sync'd.

OK, that's fine.  The best advice I can think of is to solve the right problem.

In most cases, it is easier to solve the problem of sync'ing all computers to a correct timesource (and thus all be mutually in sync), then it is to setup a bunch of truly & completely isolated machines which happen to stay in sync.  If I really had to solve the latter problem, I would likely connect the machines to a valid NTP timesource long enough to calibrate each machines' intrinsic drift from realtime, and then run time in standalone mode against their local clock.

(I'd be much likelier to see whether I can cheat that extreme restriction my using a modem line to callout to a timesource, or hit up a GPS receiver, or WWVB receiver, etc.)

Regards,
-- 
-Chuck

On 2010-03-19, Joe Wulf <joe_wulf@yahoo.com> wrote:
> Group,
>
> With due humbleness and respect to both 'cnoyes2' (the original author) and Steve Kosteke---I would think he (cnoyes2) isn't concerned with whether the clocks are monotonic (whatever that is).
>
> I understand and fully agree that unmanaged clocks, which are not 
> sync'd to an authoritative time-source will drift, and it can get 
> horrible and other bad things can happen.  Got that.
>
> What seems to get lost, and admittedly not explained very well---hence 
> my attempt here.... is that there are many situations these days where 
> folks are developing, working, troubleshooting real-world problems in 
> environments big and small that are deliberately isolated (and rightfully so)---and 
> just don't have the luxury of an authoritative time-source  --  but just want time to 'work' and be sync'd.  They are not going to get an authoritative time-source.  They are not knowledgeable/experienced 

I am sorry, but getting an authoritative time source is trivial. A
GPS18x is cheap ( a lot less than you have spent on your salary in these
postings) reliable and easy. If they do not need the microsecond
precision of PPS, they can get a serial or usb version and get
millisecond precision, which is probably all they need.  


> with ntp (raises my own hand high here).  They need meaningful technical advice (ideally from this community), broken down into layman's 
> terms, on how to establish 'the best that can be possible' in a private 
> environment knowing it will never get to have an authoritative 
> time-source.

Why not?


>
> In other words---how can we broaden folks knowledge of ntp, in enjoyable ways, tell them first what they CAN do and solve their ntp problems along the way?
>

They are being told what they can do. 



> R,
> -Joe Wulf
>  Senior IA Engineer/ISSE
>  ProSync Technology Group, LLC
>
>
>
>
> ----- Original Message ----
>> From: Steve Kostecke <kostecke@ntp.org>
>> To: questions@lists.ntp.org
>> Sent: Fri, March 19, 2010 2:56:14 PM
>> Subject: Re: [ntp:questions] Quick sync between two computers not connected to the internet
>> 
>> > On 2010-03-19, cnoyes2 <
>> > href="mailto:cnoyes2@gmail.com">cnoyes2@gmail.com> wrote:
>> >
>> > I'm trying to sync the time on 2 Windows XP computers that are not on
>> > the internet and never will be. For testing purposes, they need to
>> > have the same time. The time does not need to be accurate.
>>
>> You're not concerned about whether or not the clocks are stable or monotonic?
>>
>> Steve Kostecke

unruh <unruh@wormhole.physics.ubc.ca> wrote:
> I am sorry, but getting an authoritative time source is trivial. A
> GPS18x is cheap ( a lot less than you have spent on your salary in
> these postings) reliable and easy. If they do not need the
> microsecond precision of PPS, they can get a serial or usb version
> and get millisecond precision, which is probably all they need.

Is it still "trivial" in a below-ground data center?  Heck, even a
data center on the ground floor?  It wasn't a GPS18x, but I tried
taking a garmin GPS12 into a few machine rooms and had no joy
whatsoever getting any GPS signal.

rick jones
-- 
a wide gulf separates "what if" from "if only"
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

On Mar 23, 16:38=A0UTC, Chuck Swiger <cswiger@mac.com> wrote:
> In most cases, it is easier to solve the problem of sync'ing all computer=
s to a
> correct timesource (and thus all be mutually in sync), then it is to setu=
p a
> bunch of truly & completely isolated machines which happen to stay in syn=
c.
>=A0If I really had to solve the latter problem, I would likely connect the=
 machines
> to a valid NTP timesource long enough to calibrate each machines' intrins=
ic
> drift from realtime, and then run time in standalone mode against their l=
ocal clock.

This sounds like a good practical answer to the original question.  I
would go further and suggest only a single machine needs to have its
frequency drift tamed by ntpd to get close enough to correct that the
rest of the PCs are only very marginally more likely to have problems
syncing to that single PC than a stable external reference.

The challenge is that all the PCs (at least those that work well with
ntpd, thinking of power saving and spread-spectrum clocking woes) have
clocks that are within a few hundred parts-per-million (PPM) in
frequency with the internationally agreed length of a second.  ntpd
has a hard limit of 500 PPM for slewed correction, accomplished by
adjusting the frequency of the OS clock over the range -500 to 500
PPM.  ntpd will keep the clock crudely in sync for clocks with
frequency error too close to the limit of 500 PPM to leave enough
wiggle room for ntpd's preferred method of correcting both offset and
frequency errors by adjusting the OS clock frequency.  In that
degenerate case, ntpd will be repeatedly stepping (setting) the OS
clock, including backward steps as needed.

By running ntpd against an external time source (whether via NTP or a
local reference clock) on one machine for a few days, you should
observe its reported frequency (ntpq -c "rv 0 frequency", or as part
of ntpq -crv) settling down, and you should see the clock being
maintained with at most one step of the clock soon after starting
ntpd.  At that point, the contents of the driftfile can be assumed to
bring ntpd on that machine within a handful of PPM of correct, with
the major remaining error due to the temperature coefficient of the
crystal oscillator, which is around 1 PPM per degree Celsius.

At that point you can move/reconfigure that PC into the isolated
network and configure it to be authoritative based on its local clock,
by configuring the LOCAL refclock 127.127.1.0 and "fudging" its
stratum up (I'd suggest to 8).  Point ntpd on all the other machines
to the frequency-tamed LOCAL refclock box and before long all of them
should come in line, with their frequency correction in driftfile
settling down to eliminate most of the inherent clock drift.

The best way to keep a set of machines humming in tune is for them all
to share a single source, or for them to all agree on the priority of
sources so when the primary is unusable, they all switch to the same
next source.

The simplest way to achieve that is to use a single NTP server and
point all clients at it.  If you already have a natural central server
like a database which the need for time sync is tightly-related to,
this may be the best approach.

If you want to maintain close sync without a single point of failure,
another way is to configure several (3 or more) with the LOCAL
refclock at elevated stratum, using stratum as priority, so you might
have one each at stratum 8, 9, 10, and 11.  If the stratum 8 went
offline temporarily, everyone would switch to the stratum 9.

That is the hard way, though.  More recent versions of ntpd support
"Orphan Mode" [1] which automatically organizes all your ntpds into
agreement on a random order of priority, so that again any failures or
isolation should result in every ntpd switching to the same secondary
(etc) source.  I would suggest "tos orphan 8" if you go that route.
The elevated stratum avoids trouble when a ntpd configured for this
private network gains connectivity to "normal" ntpds synchronized
eventually to a real stratum 1 external reference, and as long as you
stay under the limit of 15, causes no pain for the isolated setup.

Cheers,
Dave Hart

[1] http://www.eecis.udel.edu/~mills/ntp/html/assoc.html#orphan

Joe Wulf wrote:
> Group,
> 
> With due humbleness and respect to both 'cnoyes2' (the original author) and Steve Kosteke---I would think he (cnoyes2) isn't concerned with whether the clocks are monotonic (whatever that is).
> 
> I understand and fully agree that unmanaged clocks, which are not 
> sync'd to an authoritative time-source will drift, and it can get 
> horrible and other bad things can happen.  Got that.
> 
> What seems to get lost, and admittedly not explained very well---hence 
> my attempt here.... is that there are many situations these days where 
> folks are developing, working, troubleshooting real-world problems in 
> environments big and small that are deliberately isolated (and rightfully so)---and 
> just don't have the luxury of an authoritative time-source  --  but just want time to 'work' and be sync'd.  They are not going to get an authoritative time-source.  They are not knowledgeable/experienced 
> with ntp (raises my own hand high here).  They need meaningful technical advice (ideally from this community), broken down into layman's 
> terms, on how to establish 'the best that can be possible' in a private 
> environment knowing it will never get to have an authoritative 
> time-source.

There is not very much that *can* be done for such people.  There is 
"orphan mode" which I have never used or needed to.  Other than that, 
NTP has little to offer people who can't get time from outside and have 
no authoritative source inside.  Maybe they could put a "sun dial" on 
the front lawn???

Rick Jones writes:
> Is it still "trivial" in a below-ground data center?

Use the NIST dialup service:
<http://tf.nist.gov/service/time-computer.html>
-- 
John Hasler 
jhasler@newsguy.com
Dancing Horse Hill
Elmwood, WI USA

> Is it still "trivial" in a below-ground data center?  Heck, even a
> data center on the ground floor?  It wasn't a GPS18x, but I tried
> taking a garmin GPS12 into a few machine rooms and had no joy
> whatsoever getting any GPS signal.
>
> rick jones

Rick, just for your information, the GPS12 is a rather deaf unit by 
today's standards - something like a GPS18x LVC or GPS 60 CSx is 
significantly more sensitive.  No, I'm not saying it works below-ground!

Cheers,
David 

On 2010-03-23, Rick Jones <rick.jones2@hp.com> wrote:
> unruh <unruh@wormhole.physics.ubc.ca> wrote:
>> I am sorry, but getting an authoritative time source is trivial. A
>> GPS18x is cheap ( a lot less than you have spent on your salary in
>> these postings) reliable and easy. If they do not need the
>> microsecond precision of PPS, they can get a serial or usb version
>> and get millisecond precision, which is probably all they need.
>
> Is it still "trivial" in a below-ground data center?  Heck, even a
> data center on the ground floor?  It wasn't a GPS18x, but I tried
> taking a garmin GPS12 into a few machine rooms and had no joy
> whatsoever getting any GPS signal.

Well, you might have to run a line out to the ground floor, or just
stick a $200 laptop with a connection to the data center. That is
slightly less trivial I agree. 

>
> rick jones

David J Taylor <david-taylor@blueyonder.co.uk.invalid> wrote:
> Rick, just for your information, the GPS12 is a rather deaf unit by
> today's standards - something like a GPS18x LVC or GPS 60 CSx is
> significantly more sensitive.  No, I'm not saying it works
> below-ground!

Understood.  So, if anyone in the vicinity of Cupertino, CA happens to
have one of these things and would care to visit... :)

rick jones
-- 
portable adj, code that compiles under more than one compiler
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

unruh <unruh@wormhole.physics.ubc.ca> wrote:
> Well, you might have to run a line out to the ground floor, or just
> stick a $200 laptop with a connection to the data center. That is
> slightly less trivial I agree.

Which leads us to the interaction between the technically
straightforward vs the administratively prohibited :)

rick jones
-- 
firebug n, the idiot who tosses a lit cigarette out his car window
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

On 2010-03-23, Rick Jones <rick.jones2@hp.com> wrote:
> unruh <unruh@wormhole.physics.ubc.ca> wrote:
>> Well, you might have to run a line out to the ground floor, or just
>> stick a $200 laptop with a connection to the data center. That is
>> slightly less trivial I agree.
>
> Which leads us to the interaction between the technically
> straightforward vs the administratively prohibited :)

That I can of course recommend nothing about. Your administration might
forbid you to install anything not sold by MS on your machines, and then
you could not install ntp at all. The vagaries of administrations
require a completely different set of things to solve. Are you sure that
they will allow you to sent ntp datagrams between the machines? Have you
asked? 


>
> rick jones

unruh wrote:

> I am sorry, but getting an authoritative time source is trivial. A
> GPS18x is cheap ( a lot less than you have spent on your salary in these
> postings) reliable and easy. If they do not need the microsecond

In many business environments it can be remarkably difficult to get 
capital expenditure approval for even quite small items, compared with 
the opportunity costs of spending staff time on the problem.

> precision of PPS, they can get a serial or usb version and get
> millisecond precision, which is probably all they need.  
> 

David Woolley <david@ex.djwhome.demon.invalid> wrote:
> unruh wrote:
>
>> I am sorry, but getting an authoritative time source is trivial. A
>> GPS18x is cheap ( a lot less than you have spent on your salary in these
>> postings) reliable and easy. If they do not need the microsecond
>
> In many business environments it can be remarkably difficult to get 
> capital expenditure approval for even quite small items, compared with 
> the opportunity costs of spending staff time on the problem.

It can also be difficult to buy items from suppliers with no existing
relationship.  I.e. it may be easy to buy new computers or supplies, but
difficult to get a GPS receiver from some online shop.
E.g. where I work it is not possible to buy anything from a shop where
creditcard or upfront payment are the only options.

> It can also be difficult to buy items from suppliers with no existing
> relationship.  I.e. it may be easy to buy new computers or supplies, but
> difficult to get a GPS receiver from some online shop.
> E.g. where I work it is not possible to buy anything from a shop where
> creditcard or upfront payment are the only options.

I used to work in a place which /was/ like that.  Fortunately, they saw 
the light, and we subsequently had one chap who could purchase up to GBP 
250 (~ US $400) on a credit card.  Much time and aggravation was saved by 
this move.  Might be worth suggesting this to your management - perhaps 
pop it in the suggestions box and earn a reward - if they have a 
suggestion box, that is!

Cheers,
David 

David J Taylor <david-taylor@blueyonder.co.uk.invalid> wrote:
>> It can also be difficult to buy items from suppliers with no existing
>> relationship.  I.e. it may be easy to buy new computers or supplies, but
>> difficult to get a GPS receiver from some online shop.
>> E.g. where I work it is not possible to buy anything from a shop where
>> creditcard or upfront payment are the only options.
>
> I used to work in a place which /was/ like that.  Fortunately, they saw 
> the light, and we subsequently had one chap who could purchase up to GBP 
> 250 (~ US $400) on a credit card.  Much time and aggravation was saved by 
> this move.  Might be worth suggesting this to your management - perhaps 
> pop it in the suggestions box and earn a reward - if they have a 
> suggestion box, that is!

Maybe I should first suggest a suggestion box? :-)

In all fairness, this policy is partly motivated by requirements from
the tax department.  A company has to have a consistent financial
bookkeeping, and part of this means that there should be invoices for
all expenditures.  The easiest way to implement this is to require an
invoice before payment is made.  That way, the invoice can be checked
for legal correctness before it is paid.
(and indeed, some invoices are returned asking for a new one with correct
company name or other detail)

When creditcard- or upfront payments are allowed, it is much harder to
enforce this control.  That is why the financial department does not
allow it.

(of course, the risk that goods are not received after upfront payment
is another one, but that is for the management to decide)

I agree with you that often a lot of time is spent, and higher prices
are paid, because of this policy.  We have a computer small parts supplier
that is at least 20% more expensive than going prices at webshops, but
we buy almost everything there because they ship same day and send
invoices for later payment.  20% could be saved on the budget by getting
a credit card or electronic banking account, but the forces decide not
to do it :-)

Rob wrote:
> I agree with you that often a lot of time is spent, and higher prices
> are paid, because of this policy.  We have a computer small parts supplier
> that is at least 20% more expensive than going prices at webshops, but
> we buy almost everything there because they ship same day and send
> invoices for later payment.  20% could be saved on the budget by getting
> a credit card or electronic banking account, but the forces decide not
> to do it :-)
Volkswagen Developement used to have a similar friendly and
subservient "helper", you could even decide what the thing you
ordered should be called on the invoice. markup: 100% ;-)

The common (auto)misconception that Bookkeeping ( or IT in recent
years ) is the essence of a productive department with all others
trailing in "Wichtigkeit" and supportive utility.
	( and not in the supportive role they actually occupy )

uwe

In article <7C492E13-48C4-4B06-84EA-81E4E6596CA7@mac.com>,
 Chuck Swiger <cswiger@mac.com> wrote:
> 
> In most cases, it is easier to solve the problem of sync'ing all computers to 
> a correct timesource (and thus all be mutually in sync), then it is to setup 
> a bunch of truly & completely isolated machines which happen to stay in sync. 
>  If I really had to solve the latter problem, I would likely connect the 
> machines to a valid NTP timesource long enough to calibrate each machines' 
> intrinsic drift from realtime, and then run time in standalone mode against 
> their local clock.

How good does the timekeeping need to be?  Was the max error ever stated?

Anyway, what I have done in such situations is to anoint a freewheeling ordinary 
workstation as the "NTP Timeserver" (trumpet flare please), and have everybody 
else synch to it.  Synch to external time is by eyeball and wistwatch.  This 
approach does keep them all together, but their sense of time is a good 
indicator of the local temperature wherever that anointed workstation is 
installed.

That said, it is admittedly an approach taken only in desperation, and GPS-based 
NTP timeservers are cheap - just buy the box, install it on the network, and 
point everybody to it.

Joe Gwinn

On Mar 23, 11:38=A0am, Chuck Swiger <cswi...@mac.com> wrote:
>
> If I really had to solve the latter problem, I would likely connect the m=
achines to a valid NTP timesource long enough to calibrate each machines' i=
ntrinsic drift from realtime, and then run time in standalone mode against =
their local clock.

Useless.  Clocks may drift wildly due to temperature changes, be it
ambient or inside the box.

On Mar 23, 1:34=A0pm, "Richard B. Gilbert" <rgilber...@comcast.net>
wrote:
> There is
> "orphan mode" which I have never used or needed to.

I'm a big fan of orphan mode and, when the DSL goes out, it's pretty
fun to see my systems at home settling on one of them to be the ref.
It is perhaps the answer to the OP question.

HTH

Evandro Menezes writes:
> Useless.  Clocks may drift wildly due to temperature changes, be it
> ambient or inside the box.

Irrelevant if the machines only need to be synchronized with each
other.  From what I can tell of the OP's requirements the two machines
could be hours from UTC and it wouldn't matter as long as they are
within milliseconds of each other.
-- 
John Hasler 
jhasler@newsguy.com
Dancing Horse Hill
Elmwood, WI USA

In article <0f5de21d-2a20-40fa-ab68-a03cba5ae90b@u9g2000yqb.googlegroups.com>,
 Evandro Menezes <evandro@mailinator.com> writes:
>On Mar 23, 11:38=A0am, Chuck Swiger <cswi...@mac.com> wrote:
>>
>> If I really had to solve the latter problem, I would likely connect the m=
>achines to a valid NTP timesource long enough to calibrate each machines' i=
>ntrinsic drift from realtime, and then run time in standalone mode against =
>their local clock.
>
>Useless.  Clocks may drift wildly due to temperature changes, be it
>ambient or inside the box.

The temperature drifts that I've seen are much smaller than the
basic calibration.

On the other hand recent Linux kernels have screwed up the basic
calibration on startup so rebooting a machine is much worse than
a temperature change.  (If they have fixed it recently, I haven't
seen any announcement.  You can fix it by hacking a constant into
your kernel.)

-- 
These are my opinions, not necessarily my employer's.  I hate spam.

On 2010-03-24, Evandro Menezes <evandro@mailinator.com> wrote:
> On Mar 23, 11:38?am, Chuck Swiger <cswi...@mac.com> wrote:
>>
>> If I really had to solve the latter problem, I would likely connect the machines to a valid NTP timesource long enough to calibrate each machines' intrinsic drift from realtime, and then run time in standalone mode against their local clock.
>
> Useless.  Clocks may drift wildly due to temperature changes, be it
> ambient or inside the box.

Not useless, but not high accuracy either. You will probably get it to
within a few parts per million (Ie, a second per day) with fluctuations
around that. while the bare board will give you more like 10-100PPM out. 

On 2010-03-24, Hal Murray <hal-usenet@ip-64-139-1-69.sjc.megapath.net> wrote:
> In article <0f5de21d-2a20-40fa-ab68-a03cba5ae90b@u9g2000yqb.googlegroups.com>,
>  Evandro Menezes <evandro@mailinator.com> writes:
>>On Mar 23, 11:38=A0am, Chuck Swiger <cswi...@mac.com> wrote:
>>>
>>> If I really had to solve the latter problem, I would likely connect the m=
>>achines to a valid NTP timesource long enough to calibrate each machines' i=
>>ntrinsic drift from realtime, and then run time in standalone mode against =
>>their local clock.
>>
>>Useless.  Clocks may drift wildly due to temperature changes, be it
>>ambient or inside the box.



>
> The temperature drifts that I've seen are much smaller than the
> basic calibration.
>
> On the other hand recent Linux kernels have screwed up the basic
> calibration on startup so rebooting a machine is much worse than
> a temperature change.  (If they have fixed it recently, I haven't
> seen any announcement.  You can fix it by hacking a constant into
> your kernel.)
Yes, it seems to be fixed. My machines with the more recent kernels are
getting about 10PPM out, while the older ones with the calibration
problems are more like 100-200PPM out.
and varying by 50PPM or so between boots. 
>

> > On the other hand recent Linux kernels have screwed up the basic
> > calibration on startup so rebooting a machine is much worse than a
> > temperature change.  (If they have fixed it recently, I haven't
> > seen any announcement.  You can fix it by hacking a constant into
> > your kernel.)

> Yes, it seems to be fixed. My machines with the more recent kernels
> are getting about 10PPM out, while the older ones with the
> calibration problems are more like 100-200PPM out.  and varying by
> 50PPM or so between boots.

Which kernel versions are we talking about here, and are the fixes
backported to distro kernels?

rick jones
-- 
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

On 2010-03-24, Rick Jones <rick.jones2@hp.com> wrote:
>> > On the other hand recent Linux kernels have screwed up the basic
>> > calibration on startup so rebooting a machine is much worse than a
>> > temperature change.  (If they have fixed it recently, I haven't
>> > seen any announcement.  You can fix it by hacking a constant into
>> > your kernel.)
>
>> Yes, it seems to be fixed. My machines with the more recent kernels
>> are getting about 10PPM out, while the older ones with the
>> calibration problems are more like 100-200PPM out.  and varying by
>> 50PPM or so between boots.
>
> Which kernel versions are we talking about here, and are the fixes
> backported to distro kernels?

Mandriva 2008.1 has the problems ( kernel 2.6.24 various Mandriva
versions. )
Mandriva 2010.0 ( kernel 2.6.31 various versions) does not seem to have the
problem.

I do not think that it is Mandriva backported patches, but the kernel
itself, but could not swear to it.


I have not made an extensive study since chrony does a good job of
compensating for the problems-- fast convergence after reboot-- so I
have not worried about it too much.


>
> rick jones

Subject was:  Re: [ntp:questions] Quick sync between two computers not
connected to the internet


Chuck,

I hear what you are saying---yet the fact remains of the need by some
(myself numerous times) to
work in a vacuum; an environment that is deliberately and politically
restricted from connection to
the internet, or where the extra purchase of some form of internal and
private NTP source might
otherwise have been available.  An environment where your first attempt with
the sneaky-modem
would, most likely, get you fired   <smile>   ...    yea, some environments
really are like this.

The right problem to solve, usually as a precursor to the real work we get
paid for, is to have these
isolated systems 'effectively' in sync, time-wise, with some facsimile of
real time synchronization.

As a precursor to that, is the search for documentation on NTP, its protocal
and how to 'set it up'
in such a private environment, so that it works.  That search, for me,
continues.

You said:  "In most cases, it is easier to solve the problem of sync'ing all

computers to a correct
                 timesource (and thus all be mutually in sync)...".
I think I agree with that principal, though I don't yet feel I know enough
to 'do it'.  Would like to
have your (and others') help in learning the nuts-and-bolts of understanding
that, and how to
accomplish it.


Finally, ... maybe the documentation I'm looking for doesn't exist---or the
problem set is to
technical for me to grok, but way to simplistic for the majority of
ntpquestions list members.  So,
maybe I need to dig in even further, connect with a few ntp experts, and
write the documentation
myself that I'm looking for.


Thank you for taking a stab at this.  Much appreciated.


R,
-Joe Wulf
 Senior IA Engineer/ISSE
 ProSync Technology Group, LLC



----- Original Message ----
> From: Chuck Swiger 
<cswiger@mac.com>
>  ----- Original Message ----
>  > On Mar 19, 2010, at 1:19 PM, Joe Wulf wrote:
>  > > Group,

<snip>

>  In most cases, it is easier to solve the problem of sync'ing all
computers to a correct timesource
>  (and thus all be mutually in sync), then it is to setup a bunch of truly
& 
completely isolated
>  machines which happen to stay in sync.  If I really 
had to solve the latter problem, I would likely
>  connect the machines to a valid NTP timesource long enough to calibrate
each machines'
>  intrinsic 
drift from realtime, and then run time in standalone mode against their 
local clock.

>  (I'd be much likelier to see whether I can cheat that extreme 
restriction my using a modem line
>  to callout to a timesource, or hit up a GPS receiver, or WWVB receiver,
etc.)

>  Regards,
>  -- 
>  -Chuck

On 2010-03-25, Joe Wulf <joe_wulf@yahoo.com> wrote:
> Subject was:  Re: [ntp:questions] Quick sync between two computers not
> connected to the internet
>
>
> Chuck,
>
> I hear what you are saying---yet the fact remains of the need by some
> (myself numerous times) to
> work in a vacuum; an environment that is deliberately and politically
> restricted from connection to
> the internet, or where the extra purchase of some form of internal and
> private NTP source might
> otherwise have been available.  An environment where your first attempt with
> the sneaky-modem
> would, most likely, get you fired   <smile>   ...    yea, some environments
> really are like this.

One possibility if you have at least one Linux or BSD machine around is
to use chrony as the server. It is designed to use various sources,
including your wristwatch as an outside time source. Then the other
systems can sync to that under ntpv3 protocol. 

If you have only Windows machines, then that option does not work.



>
> The right problem to solve, usually as a precursor to the real work we get
> paid for, is to have these
> isolated systems 'effectively' in sync, time-wise, with some facsimile of
> real time synchronization.
>
> As a precursor to that, is the search for documentation on NTP, its protocal
> and how to 'set it up'
> in such a private environment, so that it works.  That search, for me,
> continues.

doc.ntp.org
for documentation. 


>
> You said:  "In most cases, it is easier to solve the problem of sync'ing all
>
> computers to a correct
>                  timesource (and thus all be mutually in sync)...".
> I think I agree with that principal, though I don't yet feel I know enough
> to 'do it'.  Would like to
> have your (and others') help in learning the nuts-and-bolts of understanding
> that, and how to
> accomplish it.

It means that you have one ( or two ) computers sync to an external
source and then use that machine as the source for the others. 

>
>
> Finally, ... maybe the documentation I'm looking for doesn't exist---or the
> problem set is to
> technical for me to grok, but way to simplistic for the majority of
> ntpquestions list members.  So,
> maybe I need to dig in even further, connect with a few ntp experts, and
> write the documentation
> myself that I'm looking for.

See above.

>
>
> Thank you for taking a stab at this.  Much appreciated.
>
>
> R,
> -Joe Wulf
>  Senior IA Engineer/ISSE
>  ProSync Technology Group, LLC
>
>
>
> ----- Original Message ----
>> From: Chuck Swiger 
><cswiger@mac.com>
>>  ----- Original Message ----
>>  > On Mar 19, 2010, at 1:19 PM, Joe Wulf wrote:
>>  > > Group,
>
><snip>
>
>>  In most cases, it is easier to solve the problem of sync'ing all
> computers to a correct timesource
>>  (and thus all be mutually in sync), then it is to setup a bunch of truly
> & 
> completely isolated
>>  machines which happen to stay in sync.  If I really 
> had to solve the latter problem, I would likely
>>  connect the machines to a valid NTP timesource long enough to calibrate
> each machines'
>>  intrinsic 
> drift from realtime, and then run time in standalone mode against their 
> local clock.
>
>>  (I'd be much likelier to see whether I can cheat that extreme 
> restriction my using a modem line
>>  to callout to a timesource, or hit up a GPS receiver, or WWVB receiver,
> etc.)
>
>>  Regards,
>>  -- 
>>  -Chuck

In article <075646E21C534B2485FE3630B42F0936@f9x54b1>,
 "Joe Wulf" <joe_wulf@yahoo.com> writes:
>Subject was:  Re: [ntp:questions] Quick sync between two computers not
>connected to the internet

>As a precursor to that, is the search for documentation on NTP, its protocal
>and how to 'set it up'
>in such a private environment, so that it works.  That search, for me,
>continues.

We should get a wiki page to cover this.  Until then, here is my
checklist:

1:  Get a source of time
  network connection
    (solving the political issue may be easier than the alternatives)
  Commercial box
    (probably wants external antenna)
  refclock (check the list)
    GPS is under $100
      may not work in machine rooms
    ACTS/phone
    rest of refclock list

2:  Orphan mode

3:  Pick one system to use as the server
    Use local refclock
    You can hand tune the drift to get within a second per day or so
      (Some Linux kernels are broken - screwup on reboot)
    Or run on the internet for a while so ntpd will find the drift.


-- 
These are my opinions, not necessarily my employer's.  I hate spam.

unruh wrote:
>> You said:  "In most cases, it is easier to solve the
>>  problem of sync'ing all computers to a correct timesource
>>  (and thus all be mutually in sync)...".
>> I think I agree with that principal, though I don't yet
>>  feel I know enough to 'do it'.  Would like to have your
>>  (and others') help in learning the nuts-and-bolts of
>>  understanding that, and how to accomplish it.
>
> It means that you have one ( or two ) computers sync to
>  an external source and then use that machine as the
>  source for the others.

It doesn't have to be an "external source", if cheap is
 not a goal, and isolation from the rest of the world is.

 They can get their own in-house frequency standard(s),
  to PPS discipline their NTP server(s).


I'm certain the sales people at Symmetricom could provide
 them with NTP servers that don't make use of any outside
 world references.
 <symmetricom.com/products/ntp-servers/modular-ntp-solutions/>

 symmetricom.com sells Cesium, Rubidium and Hydrogen Maser Standards

 quartzlock.com sells Rubidium Standards
    (and used to sell Hydrogen Maser Standards?)

 novatech-instr.com sells Rubidium Standards


 Selecting a Primary Frequency Standard for a Calibration Laboratory
  (Cal Lab Int. Jour. of Metrology, April 2008, pp. 33-39)
   <tf.nist.gov/general/pdf/2289.pdf>


-- 
E-Mail Sent to this address <BlackList@Anitech-Systems.com>
  will be added to the BlackLists.

On 2010-03-25, E-Mail Sent to this address will be added to the BlackLists <Null@BlackList.Anitech-Systems.invalid> wrote:
> unruh wrote:
>>> You said:  "In most cases, it is easier to solve the
>>>  problem of sync'ing all computers to a correct timesource
>>>  (and thus all be mutually in sync)...".
>>> I think I agree with that principal, though I don't yet
>>>  feel I know enough to 'do it'.  Would like to have your
>>>  (and others') help in learning the nuts-and-bolts of
>>>  understanding that, and how to accomplish it.
>>
>> It means that you have one ( or two ) computers sync to
>>  an external source and then use that machine as the
>>  source for the others.
>
> It doesn't have to be an "external source", if cheap is
>  not a goal, and isolation from the rest of the world is.
>
>  They can get their own in-house frequency standard(s),
>   to PPS discipline their NTP server(s).
>
>
> I'm certain the sales people at Symmetricom could provide
>  them with NTP servers that don't make use of any outside
>  world references.

Sure, for a few tens or hundreds of thousands of dollars. When a gps
puck is $100, plus some wire. I would suspect that they would be more
willing to spend $200 for a p\gps puck and some wire, than $100000 for a
H Maser clock, but who knows, maybe not. On the other hand all he wanted
was to sync the computers to each other, and learning about orphan mode
should only cost a few $100 in his time and salary as well.


> <symmetricom.com/products/ntp-servers/modular-ntp-solutions/>
>
>  symmetricom.com sells Cesium, Rubidium and Hydrogen Maser Standards
>
>  quartzlock.com sells Rubidium Standards
>     (and used to sell Hydrogen Maser Standards?)
>
>  novatech-instr.com sells Rubidium Standards
>
>
>  Selecting a Primary Frequency Standard for a Calibration Laboratory
>   (Cal Lab Int. Jour. of Metrology, April 2008, pp. 33-39)
>    <tf.nist.gov/general/pdf/2289.pdf>
>
>

Hal Murray wrote:

>     You can hand tune the drift to get within a second per day or so
>       (Some Linux kernels are broken - screwup on reboot)

Hand setting is possible to about 30 seconds a year, as long as the 
machine is lightly loaded, has no aggressive power management, and is in 
an air conditioned computer room.

You can use a portable radio clock or wristwatch as the reference, and, 
with a bit of practice, can read the time to 200ms or batter against 
that, then baseline the drift over about a week and calibrate it out.