- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - HP-UX
- >
- Re: xntp strange behaviour
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Discussions
Forums
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО06-28-2009 09:36 PM
тАО06-28-2009 09:36 PM
after configed xntp server,but find some information on all our HP-UX server's syslog. what problem??
every HP-UX server configed:
#vi /etc/rc.config.d/netdaemons
export NTPDATE_SERVER=10.150.32.7
export XNTPD=1
#vi /etc/ntp.conf
server 10.150.32.7
fudge 127.127.1.1 statum 10
driftfile /etc/ntp.drift
broadcastclient yes
and syslog was behavior:
Jun 28 23:24:57 hp1 xntpd[7694]: time reset (step) 0.983834 s
Jun 28 23:24:57 hp1 xntpd[7694]: synchronisation lost
Jun 28 23:30:16 hp1 xntpd[7694]: synchronized to 10.150.32.7, stratum=13
Jun 28 23:32:24 hp1 xntpd[7694]: synchronisation lost
Jun 28 23:33:28 hp1 xntpd[7694]: synchronized to 10.150.32.7, stratum=13
Jun 29 00:06:36 hp1 xntpd[7694]: time reset (step) 0.988878 s
Jun 29 00:06:36 hp1 xntpd[7694]: synchronisation lost
Jun 29 00:11:54 hp1 xntpd[7694]: synchronized to 10.150.32.7, stratum=13
Jun 29 00:40:46 hp1 xntpd[7694]: time reset (step) 0.982435 s
Jun 29 00:40:46 hp1 xntpd[7694]: synchronisation lost
Jun 29 00:46:04 hp1 xntpd[7694]: synchronized to 10.150.32.7, stratum=13
Jun 29 01:28:29 hp1 xntpd[7694]: time reset (step) 0.979637 s
Jun 29 01:28:29 hp1 xntpd[7694]: synchronisation lost
Jun 29 01:33:47 hp1 xntpd[7694]: synchronized to 10.150.32.7, stratum=13
Thanks a lot!
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО06-28-2009 09:52 PM
тАО06-28-2009 09:52 PM
Re: xntp strange behaviour
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО06-29-2009 01:56 AM
тАО06-29-2009 01:56 AM
SolutionYou've configured xntpd to use the server's internal clock as one of its time sources (fudge 127.127.1.1 stratum 10). The NTP server 10.150.32.7 gives you stratum 13 time.
Stratum 10 is better than stratum 13, so your configuration is saying that your server's internal clock is more reliable than the NTP server.
On the other hand, your configuration does not actually tell ntpd to _use_ 127.127.1.1 for anything, so the fudge line may not be important.
The stratum value depicts the server's "distance" from a reliable source of time information. Stratum 0 would be e.g. a GPS receiver or an atomic clock itself. Stratum 1 server is directly connected to a stratum 0 device. Any NTP server that gets time from a stratum 1 server becomes itself a stratum 2 server, etc.
Your HP-UX gets stratum 13 time from 10.150.32.7, which means 10.150.32.7 must be at stratum 12. That indicates the quality of 10.150.32.7's time information might not be very good. You can easily get stratum 2 or 3 from most public NTP servers on the Internet.
Because you have just one NTP server configured, your xntpd cannot determine which of the clocks is faulty: the local clock or the 10.150.32.7's clock?
With multiple NTP servers configured, xntpd can identify which time sources seem to agree with each other and ignore the outliers.
If you want to use a public NTP server, pick one that is reasonably close to you, so that the travel time of NTP data packets becomes as small as possible. You can find lists of public NTP servers here:
http://support.ntp.org/bin/view/Servers/WebHome
If you don't have access to any public NTP servers, please read the documentation about the use of the local clock, written by the author of xntpd:
http://www.eecis.udel.edu/~ntp/ntp_spool/html/drivers/driver1.html
MK
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО06-29-2009 02:27 AM
тАО06-29-2009 02:27 AM
Re: xntp strange behaviour
ntpupdate -q
ntp will only update if the server is out of adjustment by less than a few hours.
I've seen some pretty unusual behavior using Windows as an ntp server, and there might be some patching required in that area.
SEP
Owner of ISN Corporation
http://isnamerica.com
http://hpuxconsulting.com
Sponsor: http://hpux.ws
Twitter: http://twitter.com/hpuxlinux
Founder http://newdatacloud.com
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО06-29-2009 04:56 AM
тАО06-29-2009 04:56 AM
Re: xntp strange behaviour
Bill Hassell, sysadmin
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-01-2009 11:38 PM
тАО07-01-2009 11:38 PM
Re: xntp strange behaviour
so i change the config and delete 2 line
then:
#vi /etc/ntp.conf
server 10.150.32.7
driftfile /etc/ntp.drift
after monitor one day,syslog always log,and still time rest and synchronisation lost act again,just like before log.
my environment can't connected internet,can't used public NTP server.
if i set local clock,whether solve my problem?and if can how set config?like this?
#vi /etc/ntp.conf
server 10.150.32.7
driftfile /etc/ntp.drift
fudge 127.127.1.1 stratum 10
stratum level can use number less than 13?
Or can i set ntp to broadcast colock on my loacal net ?
server 10.150.32.7
driftfile /etc/ntp.drift
fudge 127.127.1.1 stratum 10
broadcast ??????
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-02-2009 12:59 AM
тАО07-02-2009 12:59 AM
Re: xntp strange behaviour
server 127.127.1.1
fudge 127.127.1.1 stratum 6
broadcastclient no
This tells your xntpd to use your local clock time as a synchronization source (the "server" line), and to assume that it is "better" than the time information from the Windows server (the "fudge" line).
Stratum 6 is still a lot "worse" than a real time source, so if you some day get a connection to a public NTP server or purchase a GPS time receiver, the xntpd will automatically prefer it over the local clock of this server.
Stratum 6 also ensures that if/when the Windows server is configured to synchronize to your HP-UX server, it will prefer the time from HP-UX server over its own local clock.
The "driftfile" line makes xntpd to maintain a correction factor for your local clock. It is used to "auto-calibrate" the local clock over time if you have better timesources. If a connection to better timesources is lost, xntpd will use the correction factor in the drift file to minimize the error of the local clock.
If you want to use broadcast (within a single network segment only), set:
broadcast
MK
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-02-2009 01:54 AM
тАО07-02-2009 01:54 AM
Re: xntp strange behaviour
if i use local clock like your suggestions in my network,whether my hpux server time was not correct after long period of time?.
One thing was the windows server(10.150.32.7) was ntp server now├п┬╝ Because it was synchro with the satellite.many servers are synchro with this windowns server,OS include windows/aix/linux.This windows server was an unique timesources on my environment. mean it was only one NTP server.
now my hpux servers's time was often imprecise. so i use NTP config,and want to correct hpux server's time.But the result is time was ok,but syslog note lot of information about synchronized action usualy.