NTP - best practice if there is a local stratum 2 server

  • Follow


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)

Similiar Articles:


















7/26/2012 3:57:53 PM


Reply: