NTP error: time error 1073796336.000000 is way too large (set clock manually)

[Sunil Sharma_1]

Hi all,

Some of my servers are giving this problem.

OS: HP UX 11i

Regards
Sunil

[Pedro Cirne]

Hi,

You have to first adjust time manually before the daemon can do it automatically (this is because the difference is too high).

Try:

#ntpdate [ntp_server]

Errors will stop.

Enjoy :)

[Mauro Gatti]

I don't know if the error you reported matters but usually if time gap is higer then 1 hour ntp don't syncronize clock asking you to do it manually.

RGDS

[Devender Khatana]

Hi,

Yes it is due to huge diffrence in time when initially starting the synchnization. You could try to resync after reducing time by manually putting it to approximate value and could also try by restarting the xntp daemon after adjusting time manually.

HTH,
Devender

[Sunil Sharma_1]

I can see time difference is too high my question is why it happened ?

Here is the o/p from syslog. It was going smoothly and all of sudden gave this error and stopped sync.

May 28 17:44:35 mali xntpd[2522]: synchronized to 10.202.254.10, stratum=4
May 28 17:46:30 mali xntpd[2522]: synchronized to 10.202.19.190, stratum=4
May 28 17:48:15 mali xntpd[2522]: synchronized to 10.202.19.189, stratum=3
May 29 16:01:36 mali xntpd[2522]: synchronized to 10.202.19.190, stratum=3
May 29 16:05:52 mali xntpd[2522]: synchronized to 10.202.19.189, stratum=3
May 29 19:09:51 mali xntpd[2522]: synchronized to 10.202.19.200, stratum=3
May 29 19:18:19 mali xntpd[2522]: synchronized to 10.202.19.201, stratum=3
May 29 19:25:08 mali xntpd[2522]: synchronized to 10.202.19.190, stratum=3
May 29 19:26:13 mali xntpd[2522]: synchronized to 10.202.19.189, stratum=3
May 29 19:34:34 mali xntpd[2522]: synchronized to 10.202.19.190, stratum=3
May 29 19:38:48 mali xntpd[2522]: synchronized to 10.202.19.189, stratum=3
May 29 19:38:48 mali xntpd[2522]: synchronized to 10.202.19.189, stratum=3
Jun 4 19:40:29 mali xntpd[2522]: synchronized to 10.202.19.190, stratum=4
Jun 4 19:40:29 mali xntpd[2522]: time error 1073796336.000000 is way too large (set clock manually)
Jul 19 23:57:46 mali xntpd[4480]: tickadj = 625, tick = 10000, tvu_maxslew = 61875
Jul 19 23:57:46 mali xntpd[4480]: precision = 12 usec
Jul 20 00:02:36 mali xntpd[4480]: synchronized to 10.202.19.189, stratum=11
Jul 20 00:02:36 mali xntpd[4480]: synchronized to 10.202.19.201, stratum=10
Jul 20 00:10:04 mali xntpd[4480]: synchronized to 10.202.19.190, stratum=10
Jul 20 00:21:00 mali xntpd[4480]: synchronized to 10.202.19.200, stratum=10
Jul 20 00:22:27 mali xntpd[4480]: synchronized to 10.202.19.190, stratum=10
Jul 20 00:23:05 mali xntpd[4480]: synchronized to 10.202.19.189, stratum=9
Jul 20 00:34:59 mali xntpd[4480]: synchronized to 10.202.19.190, stratum=10
Jul 20 00:36:02 mali xntpd[4480]: synchronized to 10.202.19.189, stratum=9
Jul 20 00:39:14 mali xntpd[4480]: synchronized to 10.202.19.200, stratum=10
Jul 20 00:41:11 mali xntpd[4480]: synchronized to 10.202.19.190, stratum=10
Jul 20 00:47:50 mali xntpd[4480]: synchronized to 10.202.19.201, stratum=9
Jul 20 00:55:45 mali xntpd[4480]: synchronized to 10.202.254.3, stratum=10

Sunil

[Florian Heigl (new acc)]

This seems like Your upstratum server has severe issues, not Your host.

- it lost connection to stratum 3/4 servers and fell back to much worse stratum 9/10 servers
- the time difference makes it look like those servers are running unsynced.

- I'd be keen to know if Your systems' clock is really this far ( 1073796336s) off UTC, i bet it is not.

- have a try using the well-monitored servers available at pool.ntp.org

run
ntpdate -d -v pool.ntp.org

and paste the output, if You wish.

gather data on these stratum 9/10 servers.


[as a side note, not to worry yet, but to keep in mind:
for a large scale attack it would be regular procedure to first break off the original timeservers and then supply irregular time to waste logs.]

[Jeff Schussele]

Hi Sunil,

NYP can only slew time within a 999 second range - approx 15 minutes. If the diff is outside that range then you must manually bring it within with the date command before starting NTP.

Rgds,
Jeff

[Sunil Sharma_1]

Patch Level is Dec 2002.

Will it help if i will install latest patch ?

Regards
Sunil

[Florian Heigl (new acc)]

On my current system I see some patches for NTP, You may want to check if You have them or not.

PHNE_24512.INETSVCS-BOOT: /sbin/init.d/xntpd
PHNE_24512.INETSVCS-BOOT: /usr/sbin/xntpd

BUT:
Your problem is - from what I can tell - not related to the local ntp daemon, but to the time servers You use.

If You want, You can email me on monday (I'm offline over weekends at the moment) at floh ..a..t.. deranfangvomen.de

NTP is kind of my personal favorite toy, so I'll gladly debug a bit more. ;)

[Bill Hassell]

As mentioned, your NTP servers are having a problem. To see what is happening with them, use the command:

/usr/sbin/ntpq -p

The first number of interest is "reach" which should always be 377 and that means a reliable connection. The next is "poll" which is the time interval (in seconds) for the next query. For a solid, reliable connection, the number will be large (1024 which is the max, about 17 mnutes). 64 is the minimum and represents a less stable connection (for the moment).

"dispersion" is a measure of the variation for time values (and we're talking fractions of a second in variation here). Less than 1.0 is good, larger values indicate a jittery sync protocol.

Myy guess is that some or most of your time servers are not accessible or something has gone wrong with one or more of them, perhaps a network router is cutting off port 123, the ntp protocol port.

NTP is extremely stable and will not try to follow a server that changes too fast. NTP will ensure that exactly 86400 seconds will tick in your computer and may slightly adjust the time between ticks to keep in sync. But it simply stops making changes when the local time and the server are unreasonably large. Perhaps someone decide to change the time of day to a different timezone on your NTP server.

[Jagadeesh Kumar]

Sunil,

I have seen the above errors, mostly when there is network glith between NTP client and NTP server.

HTH
-Jagadeesh.