I'm trying to set up the time on a couple of machines at the University
of Washington and have tried two ways:
1) Sync both to the ntp pool - not very successful, as they kept
differing by enough to cause 'make' to say files were created in the
future by a few ms - no doubt due the NFS exported drives.
2) Set one via ntpd (call is master) from the ntp pool, then the other
local machine (slave) read the time from the master. That appears to
work quite well. They at least agree on the time pretty closely now. The
absolute accuracy might not be as good as possible with a local time
server, but for practical purposes it works well.
Searching around, I found that the university does in fact have their
own strtatum 2 time server - I assume in another department to where the
machines I'm using are located. The server is
bigben.cac.washington.edu
I assume, for absolute accuracy (which is not important here, but I'm
intersted), this is going to be better than any attempt to set the time
from the ntp pool. Is that correct?
But setting the time from the local server is also going to be cause a
problem if that server fails for some reason.
Is there any way to make use of a local server if it's working, and then
use the pool if its not?
To be honest, this is all a bit academic, as there is no real practical
need to have an accuracy of better than a minute or two on these
machines. In fact, an hour wrong would not make much difference but it
might irritate a few people.
But it is important the two machine agree with each other, as otherwise
files appear to be created in the future by a few ms, which screws up
the 'make' program some times.
--
I respectfully request that this message is not archived by companies as
unscrupulous as 'Experts Exchange' . In case you are unaware,
'Experts Exchange' take questions posted on the web and try to find
idiots stupid enough to pay for the answers, which were posted freely
by others. They are leeches.
|
|
0
|
|
|
|
Reply
|
Dave
|
6/28/2009 4:19:14 PM |
|
Dave <foo@coo.com> wrote:
> I assume, for absolute accuracy (which is not important here, but I'm
> intersted), this is going to be better than any attempt to set the time
> from the ntp pool. Is that correct?
You never know that.
What you get from the pool may be a stratum-1 server locked to GPS time
on a fast unloaded connection, or it may be a slow box on a saturated
ADSL line and synchronized to time.windows.com.
Your local server will be better to depend on. You at least know what
you get, and/or you can ask the department it belongs to what quality
you can expect. You can never do that with the pool.
> But setting the time from the local server is also going to be cause a
> problem if that server fails for some reason.
True.
> Is there any way to make use of a local server if it's working, and then
> use the pool if its not?
Of course. When you configure the local server as a "prefer" server, it
will usually work out that way.
> To be honest, this is all a bit academic, as there is no real practical
> need to have an accuracy of better than a minute or two on these
> machines. In fact, an hour wrong would not make much difference but it
> might irritate a few people.
>
> But it is important the two machine agree with each other, as otherwise
> files appear to be created in the future by a few ms, which screws up
> the 'make' program some times.
Then you should, as you do, synchronize one to the other or both of them
to the same (local) third server.
|
|
0
|
|
|
|
Reply
|
Rob
|
6/28/2009 6:01:23 PM
|
|
Dave wrote:
> I'm trying to set up the time on a couple of machines at the University
> of Washington and have tried two ways:
>
> 1) Sync both to the ntp pool - not very successful, as they kept
> differing by enough to cause 'make' to say files were created in the
> future by a few ms - no doubt due the NFS exported drives.
>
>
> 2) Set one via ntpd (call is master) from the ntp pool, then the other
> local machine (slave) read the time from the master. That appears to
> work quite well. They at least agree on the time pretty closely now. The
> absolute accuracy might not be as good as possible with a local time
> server, but for practical purposes it works well.
>
> Searching around, I found that the university does in fact have their
> own strtatum 2 time server - I assume in another department to where the
> machines I'm using are located. The server is
>
> bigben.cac.washington.edu
>
> I assume, for absolute accuracy (which is not important here, but I'm
> intersted), this is going to be better than any attempt to set the time
> from the ntp pool. Is that correct?
Accuracy should be in the very low milliseconds; e.g. plus or minus five
milliseconds. You should configure a minimum of four timeservers using
systems near you in "net space".
A system may be physically within a few hundred yards and still be
several miles away as far as signal transmission is concerned.
>
> But setting the time from the local server is also going to be cause a
> problem if that server fails for some reason.
>
That's one of the reasons why you are advised to configure four or more
servers!
> Is there any way to make use of a local server if it's working, and then
> use the pool if its not?
Configure four servers and you can survive the loss of one. Configure
five and you can survive the failure of two. Configure seven and
survive the failure of three. Failure can mean either incorrect time or
just not responding to queries.
>
> To be honest, this is all a bit academic, as there is no real practical
> need to have an accuracy of better than a minute or two on these
> machines. In fact, an hour wrong would not make much difference but it
> might irritate a few people.
>
> But it is important the two machine agree with each other, as otherwise
> files appear to be created in the future by a few ms, which screws up
> the 'make' program some times.
>
>
The machines should agree with each other reasonably well; e.g. within a
hundred or two hundred microseconds. You MAY get better than that but
remember that keeping time was not, and will not be, very high priority
in the design of any computer system. With some you may consider
yourself lucky if the date is correct.
It's easier to get and keep close synchronization if you have have some
sort of a "hardware reference clock" such as a GPS timing receiver, a
WWV receiver, etc. GPS timing receivers are available from $100 US and
up. The bottom of the scale is a bare circuit board. Moving upscale
you can get PCI cards, stylish tabletop devices, rack-mount equipment, etc.
For about $1200 US you can get a clock on a PCI card that will plug into
your computer. It will have an oven controlled crystal oscillator and
provision for a GPS input. Talk to Symmetricomm and/or Meinberg
Funkurhren; both have such hardware available.
|
|
0
|
|
|
|
Reply
|
Richard
|
6/28/2009 6:14:07 PM
|
|
Dave wrote:
> But setting the time from the local server is also going to be cause a
> problem if that server fails for some reason.
What I do here (in my home network) is make the NFS server also an NTP server, and make sure that the NFS clients prefer the NFS/NTP server over any others. (In fact: I configure those NFS clients to have only one NTP server, and that's the NFS server).
This way, as long as the NFS server is up, chances are that its NTP server will also be up.
Cheers, Jan
|
|
0
|
|
|
|
Reply
|
Jan
|
6/28/2009 6:18:19 PM
|
|
Hi,
Dave wrote:
> I'm trying to set up the time on a couple of machines at the University
> of Washington and have tried two ways:
>
> 1) Sync both to the ntp pool - not very successful, as they kept
> differing by enough to cause 'make' to say files were created in the
> future by a few ms - no doubt due the NFS exported drives.
>
>
> 2) Set one via ntpd (call is master) from the ntp pool, then the other
> local machine (slave) read the time from the master. That appears to
> work quite well. They at least agree on the time pretty closely now. The
> absolute accuracy might not be as good as possible with a local time
> server, but for practical purposes it works well.
>
> Searching around, I found that the university does in fact have their
> own strtatum 2 time server - I assume in another department to where the
> machines I'm using are located. The server is
>
> bigben.cac.washington.edu
>
> I assume, for absolute accuracy (which is not important here, but I'm
> intersted), this is going to be better than any attempt to set the time
> from the ntp pool. Is that correct?
>
> But setting the time from the local server is also going to be cause a
> problem if that server fails for some reason.
>
> Is there any way to make use of a local server if it's working, and then
> use the pool if its not?
>
> To be honest, this is all a bit academic, as there is no real practical
> need to have an accuracy of better than a minute or two on these
> machines. In fact, an hour wrong would not make much difference but it
> might irritate a few people.
>
> But it is important the two machine agree with each other, as otherwise
> files appear to be created in the future by a few ms, which screws up
> the 'make' program some times.
>
>
Init file is /etc/inet/ntp.conf
Make it easy, sync them all to a ntp server, internal or external should
not matter for the simple use you plan for(make)
You have time.apple.com for instance and tick tock
server tick.usnogps.navy.mil
server tock.usnogps.navy.mil and nasa
ntp.nasa.gov
and many more
/michael
|
|
0
|
|
|
|
Reply
|
Michael
|
6/28/2009 7:09:00 PM
|
|
Michael Laajanen wrote:
>>
> Init file is /etc/inet/ntp.conf
Not necessarily, and I suspect that this isn't even the most common
location for this file. May be it is on Solaris, but that is only
indicated by the newsgroups, not the subject or the body text.
>
> Make it easy, sync them all to a ntp server, internal or external should
Did you mean "the same NTP server"? Even if you did, they can end up
polling it at very different times.
> not matter for the simple use you plan for(make)
> You have time.apple.com for instance and tick tock
> server tick.usnogps.navy.mil
> server tock.usnogps.navy.mil and nasa
This is a bad server to use as it is overloaded. Generally very well
known servers are unlikely to be good choices, not least for the server.
> ntp.nasa.gov
>
I don't know about that one, but servers have to be chosen based on the
client location.
>
|
|
0
|
|
|
|
Reply
|
David
|
6/28/2009 10:36:30 PM
|
|
Coincidentally we just discussed the time quality of NTP server
bigben.cac.washington.edu on questions@/c.p.t.n, please see
http://lists.ntp.org/pipermail/questions/2009-June/023420.html
Cheers,
Dave Hart
|
|
0
|
|
|
|
Reply
|
Dave
|
6/29/2009 7:20:03 AM
|
|
Dave Hart wrote:
> Coincidentally we just discussed the time quality of NTP server
> bigben.cac.washington.edu on questions@/c.p.t.n, please see
>
> http://lists.ntp.org/pipermail/questions/2009-June/023420.html
>
> Cheers,
> Dave Hart
Dave,
I don't think those messages appeared on the Usenet side of the gateway.
For example, I have no messages with "cde26116.70129ab2" included.....
(Assuming c.p.t.n means comp.protocols.time.ntp)
Cheers,
David
|
|
0
|
|
|
|
Reply
|
David
|
6/29/2009 9:29:16 AM
|
|
Richard B. Gilbert wrote:
> It's easier to get and keep close synchronization if you have have some
> sort of a "hardware reference clock" such as a GPS timing receiver, a
> WWV receiver, etc. GPS timing receivers are available from $100 US and
> up. The bottom of the scale is a bare circuit board. Moving upscale
> you can get PCI cards, stylish tabletop devices, rack-mount equipment, etc.
>
> For about $1200 US you can get a clock on a PCI card that will plug into
> your computer. It will have an oven controlled crystal oscillator and
> provision for a GPS input. Talk to Symmetricomm and/or Meinberg
> Funkurhren; both have such hardware available.
Even lower on the scale is Analog Devices GPS referenced clock chip that
sync's on the 1PPS signal provided by many GPS receivers. This would be
a cool project for a hobbyist, but people with work to do would be
better off with a commercial GPS based NTP box.
- Erik
|
|
0
|
|
|
|
Reply
|
erik
|
6/30/2009 3:53:14 AM
|
|
erik magnuson wrote:
> Richard B. Gilbert wrote:
>> It's easier to get and keep close synchronization if you have have
>> some sort of a "hardware reference clock" such as a GPS timing
>> receiver, a WWV receiver, etc. GPS timing receivers are available
>> from $100 US and up. The bottom of the scale is a bare circuit
No, the bottom of the scale is the Garmin integrated GPS/serial/pps
unit, which cost ~$80. Add a $5 USB cable for power and a DB9 serial
connector and you have a sub-$100 timing source.
I believe I have read a notice about at least one guy who will sell you
an assembled & tested configuration like that.
Terje
--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"
|
|
0
|
|
|
|
Reply
|
Terje
|
6/30/2009 1:14:07 PM
|
|
Dave wrote:
> I'm trying to set up the time on a couple of machines at the University
> of Washington and have tried two ways:
>
> 1) Sync both to the ntp pool - not very successful, as they kept
> differing by enough to cause 'make' to say files were created in the
> future by a few ms - no doubt due the NFS exported drives.
>
>
> 2) Set one via ntpd (call is master) from the ntp pool, then the other
> local machine (slave) read the time from the master. That appears to
> work quite well. They at least agree on the time pretty closely now. The
> absolute accuracy might not be as good as possible with a local time
> server, but for practical purposes it works well.
>
Hi Dave,
I had a similar problem with make and clearcase back in 1998, so
purchased three clocks which were connected to three pentium II pcs
running solaris x86 and ntp (not the solaris build). They were accurate
to 1/16 of a second and were used to synchronise all Unix and Windows
equipment. You will want your NFS servers and clients using a common
pool of ntp servers.
|
|
0
|
|
|
|
Reply
|
solx
|
6/30/2009 7:23:52 PM
|
|
If you want accuracy, set up a gps clock. If not, pool is going to be good
enough. I was not impressed with bigben when I used it briefly but do not
remember the issues.
Dave <foo@coo.com> writes:
>I'm trying to set up the time on a couple of machines at the University
>of Washington and have tried two ways:
>1) Sync both to the ntp pool - not very successful, as they kept
>differing by enough to cause 'make' to say files were created in the
>future by a few ms - no doubt due the NFS exported drives.
>2) Set one via ntpd (call is master) from the ntp pool, then the other
>local machine (slave) read the time from the master. That appears to
>work quite well. They at least agree on the time pretty closely now. The
>absolute accuracy might not be as good as possible with a local time
>server, but for practical purposes it works well.
>Searching around, I found that the university does in fact have their
>own strtatum 2 time server - I assume in another department to where the
>machines I'm using are located. The server is
>bigben.cac.washington.edu
>I assume, for absolute accuracy (which is not important here, but I'm
>intersted), this is going to be better than any attempt to set the time
>from the ntp pool. Is that correct?
>But setting the time from the local server is also going to be cause a
>problem if that server fails for some reason.
>Is there any way to make use of a local server if it's working, and then
>use the pool if its not?
>To be honest, this is all a bit academic, as there is no real practical
>need to have an accuracy of better than a minute or two on these
>machines. In fact, an hour wrong would not make much difference but it
>might irritate a few people.
>But it is important the two machine agree with each other, as otherwise
>files appear to be created in the future by a few ms, which screws up
>the 'make' program some times.
>--
>I respectfully request that this message is not archived by companies as
>unscrupulous as 'Experts Exchange' . In case you are unaware,
>'Experts Exchange' take questions posted on the web and try to find
>idiots stupid enough to pay for the answers, which were posted freely
>by others. They are leeches.
|
|
0
|
|
|
|
Reply
|
Unruh
|
7/1/2009 7:45:00 AM
|
|
|
11 Replies
285 Views
(page loaded in 0.22 seconds)
|