[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

20040507: met_research3 clocl is drifting

This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.

  • Subject: 20040507: met_research3 clocl is drifting
  • Date: Fri, 07 May 2004 07:41:20 -0600
>From: Unidata Support <address@hidden>
>Organization: UCAR/Unidata
>Keywords: 200312020023.hB20N4p2027742 IDD LDM Linux GEMPAK

Hi Mai,

I noticed that the clock on met_research3 is not being set.
Is seems likely that the crontab entry that runs ntpdate or
the time server that you are trying to use is invalid.  As a
reminder, here is a piece of an exchange we had back on March 31:

 1) I've set the clock to timeserver.unidata.ucar.edu. 
 
 0,15,30,45 * * * * /usr/sbin/ntpdate timeserver > /dev/null
 
 I've put your suggested line in file 'crontab'.
 Even though there is a doubt. Your numbers are
 separated by commas whereas the other entries in the
 file were separated by spaces. So i'm not very sure
 that it will  synchronize properly. But the time is
 changed now.

I just checked and see that timeserver.unidata.ucar.edu is resolved
with no problems on met_research:

  [gempak@met_research3 ~]$ nslookup timeserver.unidata.ucar.edu
  Note:  nslookup is deprecated and may be removed from future releases.
  Consider using the `dig' or `host' programs instead.  Run nslookup with
  the `-sil[ent]' option to prevent this message from appearing.
  Server:         203.162.0.11
  Address:        203.162.0.11#53

  Non-authoritative answer:
  Name:   timeserver.unidata.ucar.edu
  Address: 128.117.140.56

So, you should be able to still use timeserver.unidata.ucar.edu as
a time server.  It would probably be better to use a time server
closer to home/in your facility.

The only reason that we care about your systems's clock is reliable
delivery of data through the LDM/IDD is based on having accurate clocks.
If a receiver's or sender's clock gets too far off, then the logic for
getting real time data no longer holds.

Cheers,

Tom
--
NOTE: All email exchanges with Unidata User Support are recorded in the
Unidata inquiry tracking system and then made publically available
through the web.  If you do not want to have your interactions made
available in this way, you must let us know in each email you send to us.