[ntp:questions] Re: Need ntpdate *tool* not *counselor*

Brian T. Brunner brian.t.brunner at gai-tronics.com
Tue May 31 17:47:00 UTC 2005

Actually I wrote to questions at lists.ntp.isc.org

My product is an embedded alarm processor.  
I log events and broadcast audio and flash the lights and clang the bells.
My Master is whatever I'm told is my Master.  
What time the Master has is the correct time, regardless.  
That's the meaning of him being Master.
It is FAR more important that we (alarm servers) all have the same 
time, which is the Masters, than that we have the "correct" time 
which is different from the Master's time.  This is why the
counsel of ntpdate should NOT be accepted.

So I want ntpdate to have a '-f' flag to force my time to this 
stratum 16 Master, because that's what I must accomplish.

If the Master is plugged in to a *real* time master (stratum 1) then fine; 
this is not likely on an oil rig offshore Angola, or 4 hours by helicopter 
from Kuala Lumpur, but criticism of the whole is not my job.  

Announcing alarms with the same time as the Master is.

Also the Master is where the Setup & Service people load new/updated 
executables and configuration files.  I'm to notice them by the time stamp.
If the Service and Setup people have flown to Downtown Kazakhstan
to install a new configuration file, but ntpdate has refused to sync time,
I could arouse a few invectives.  I'd rather we functioned drunk than 
that we failed for definable pedantic nit-picks.  Chuck a syslog entry 
warning that your best time is Stratum16, so you've no sense of the time 
being *correct*, but it is at least sync'd to the millisecond.

I conclude from the reply comments that ntpd/ntpdate are 
currently "incurably pedantic" and will not function unless *real*
time is available, they can't function without a server chain leading 
up to a stratum 1.  This is fine for the Ivory Tower folks, a drilling 
ship exploring Way Out Somewhere with operational constraints
I cannot dictate ("Thou Shalt Have a Global Time Receiver,
and thou shalt connect this GTR to a machine that I may see,
sayeth the alarm processor at the bottom of the authority chain,
or I shall smite thee by refusing to sync with anything") is another
kettle of fish.

I'll try rdate, and consider ntp/ntpdate uselessly picky.

Brian Brunner
brian.t.brunner at gai-tronics.com

>>> steve at kostecke.net 05/29/05 10:12PM >>>
In comp.protocols.time.ntp, you wrote:

> I don't own my time master and have no capacity to 'go over the head'
> of the master. I just have to accept whatever time it decides to give
> me regardless of whatever.
> So I command ntpdate -d -s -b master and I get back Server dropped,
> strata too high
> I didn't ask for ntpdate's opinion (counsel) of what height stratum
> I should be advised to consider acceptable, I wanted ntpdate to go
> (tool) get the time and use it.

The only time that ntpdate complains about a server stratum is when that
time server is operating at stratum 16 because it is not synchronized to

If you don't mind doing so I'd like to see the results of 'ntpq -p
master'. And could you please provide a brief description of how you're
attempting to set the time. A reply to the newsgroup instead of e-mail
would be fine if you prefer.

You have several choices here:

1. Choose other remote time servers (see http://ntp.isc.org/servers);
you should use at least 3 remote time servers unless you are absolutely
100% sure that you can rely upon the one that you've chosen.

2. Contact the operators of "master" and ask them why you can't
synchronize to their time server.

3. Use rdate to get the time from some other host.

4. Use HTP (http://directory.fsf.org/security/firewall/HypertextTP.html)
to get the time from web-servers.

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

This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept
for the presence of computer viruses.

www.hubbell.com - Hubbell Incorporated

More information about the questions mailing list