System clock fast, need to set it back

[Robert Milne]

Hi all HP-UXer's,

The wonderful system clock on our L1000 is running 7 minutes fast and I need to set it back for database correct transaction time stamping (local time). I would assume there should be no dramas with this, but just looking to see if there are any gotchas I need to be aware of, like time stamping in log files or whatever immediately after the time rollback.

My plan is to shut our Progress database down (of course !), shut the system down to single user mode, use the date function to set the clock back to the correct local time, wait the seven or so minutes for the actual time to pass the original system time where I rolled it back from; then reboot the system back to normal operation, and finally restart the Progress database again.

Is this reasonable ? Are there any traps for young players here, anything I should watch out for ?

Also I notice with interest in the man for date the following interesting entry:

-a [-]sss[.fff] Slowly adjust the time by sss.fff seconds (fff represents fractions of a second). This adjustment can be positive or negative. The system's clock will be sped up or slowed down until it has drifted by the number of seconds specified.

Does this mean I can apply some sort of factor to "slow" the clock until the real time "catches" up with the system time ? Maybe this is a better option to slow the clock up until system time is in sync with reality over a period of time, thereby avoiding a system shutdown and inconveniencing my users. I don't quite understand this function. Has anyone any experience with this option and/or examples as to how it works ? Any gotchas with this, particularly in relation to active databases which are time "sensitive" like Progress is ?

Any help/guidance appreciated from all you wizards.

All the best.

Rob.

[Tom Geudens]

Hi Rob,
Your procedure is fine, but just a little "add-on" :
- shut applications and databases
-- Measureware (for example) is very sensitive
-- best procedure is to go level 2 or 1
- set time (with date)
- shutdown
- interrupt the reboot and enter the PDC

*** you can wait those 7 minutes here ***

- check the time in the PDC and (if necessary) correct it there as well (is in GMT-time !!!)
- boot to level 1
- check time
- boot to level 3

Regards,
Tom

[Vincent Farrugia]

Hello,

I guess that's reasonable...

To keep your clock from running like Maurice Green, you can set it up as a time client with a local or foreign time server. You can find such servers on the internet, some having ultra-accurate time measuring technology.

Use SAM to set up this one, it's hassle-free.

HTH,
Vince

[Justo Exposito]

Hi Robert,

Another option is to configure NTP, if you have a router or other HP/UX box that has the correct time, you can configure the router as server and your L1000 as client, then you will have the same timestamps in both.

I Think that this is the better solution because you can configure it without stoping the box and the ntp software will do the synchronice between systems by seconds, perhaps in one hour you have the same timestamps.

You don't need to use the date command in order to change the time, ntp will do for you and the final result will be that you have the same date and time in both servers.

I do this and all the company boxes at this moment has the same time.

It's an easy way to do it and you can do it by sam.

Regards,

Justo.

[john korterman]

Hi,
just a thought: I do not know how long it took your system clock to gain seven minutes, but it could be interpreted as a symptom of unstable temperature in the server room. If that is the case, it could have other side-effects as well.

regards,

John K.

[John Palmer · Accepted solution]

Hi,

date -a works wonderfully well and means that you don't need to close any of your production systems. For 7 minutes fast, just use date -a -420

date - does indeed slow (or speed up) the clock until the time has been drifted by the required amount and uses the same mechanism as the NTP routines.

I've found that L class real time clocks vary, even when they're mounted in the same rack.

A technique that I use when NTP is not available is to note from observation how much the clock is out each day (I've found it to be pretty constant) and to run date -a in a regular cron job to adjust it.

Regards,
John

[Marc Dijkstra]

Hi there Rob,

I have a similar issue with 4 machines on a site, all of them are gaining time, although I have nothing to add of any use, do you mind if I hijack your thread and ask John Korterman if he could expound on the unstable temperature theory, as that is the case on this site. Is there any documentation to support this? as it would explain a lot.

Thanks for the slot!

MND

[Paul Thomson_2]

When setting back time. We use universal time as the mesaure, this being GMT.

After shutting down applications and databases.

use

date -u MMDDhhmm

Where MM = Month
DD = Day
hh = hour
mm = minute.

As we have servers around the world, the local timezone setting on server adjusts its time from GMT to calculate its local time.

[john korterman]

Hi Marc,

although the attached document deals with very specific hardware, I think it goes for all crystal oscillator driven time generators.

http://support4.itrc.hp.com/service/cki/docDisplay.do?docLocale=en_US&docId=200000024128185

regards,

John K.

[Marc Dijkstra]

John,

Thanks a stack, exactly what I was after!

Rob, thanks for the space in yer thread, muchly appreciated.

MND

[Robert Milne]

Thanks for everyone who responded, that's great !

This is one of the things I love about this forum, the answers come thick and fast and are all valuable. It must be one of the best support forums around.

Marc, thanks in particular, I think I will give the date -a option a go, I'll play with it on my demo B132L+ box (with 11.0) before I use it on the production (11i). Just one question on this, do you know at what rate this adjustment occurrs at. ie. if I do use date -a -420 how long will it take to do the adjustment, over what period of time ? Of course I will play with it and see, but just curious at to officially what the slowing/gaining rate is.

For the NTP suggestion, in the long term I think I will investigate this, but out box is behind a firewall, with most services on the box and firewall disabled so I'll tread softly and spend my time on this as a lower priority task. The L1000 is our only production HP-UX server so I have no real requirement to sync with other boxes etc.

The temperature in our server room is air-conditioned set at 20C +/- 1 probably. It shouldn't be varying too much, and we don't seem the have the same problem on other (Compaq...) servers. I think this time has drifted over a period of about 9 months, so I guess is gaining about 45 secs. per month. Which maybe isn't too bad, but then this was a $100k AUD box, and I have a $5 quartz watch that keeps better time, so maybe is not that good !

Marc, no problem with hijacking the thread, for my (rare) posts, feel free to anytime, by going off at such angles that is how we all learn stuff !

All the best, and I'll let you know how it goes, now I'll award the points to all. Again thanks for all the feedback.

Rob.

[Bill Thorsteinson]

NTP can be set using a number
of sources. If you can't get
the firewall opened for UDP port 123 to three or four
nearby (network access) servers, you can use your
own time source.

It is common now to use a GPS receiver a time source. There
are also radio clocks that sync with WWV or other time
signal broascasters.

I wouldn't consider running a production server without ntp.

There is lots of good information at http://www.ntp.org

Given your firewall issues, ntp likely will not solve your
immediate problem. If you had
access ntp can be set to slew time rather than jump it for large offsets. Default offset is 128millesecs

[Paul Szeto]

Rob,

I would recommend using NTP as well. It's safe and PERMANENT.

I am speaking out of experience. We had a G-class machine that kept on drifting in time no matter how much hardware we changed. Using the NTP protocol is the best way to maintain your system time. It makes the changes gradually until your time is correct instead of abruptly jumping to the correct time.

BTW, does the Progress database happen to be an ACE/Server?

Thanks,
Paul

[Robert Milne]

Thanks for that.

Yes NTP is definitely something we will move to in the not too distant future. Microsoft's Active Directory also supports and uses features of this as well. This will also enable us to sync our Win2K servers as well.

For now the date -a function has been great and has achieved exactly what I want. Whilst time stamping is important, it's not that critical. Being out a minute or two is OK, it's just that it was getting too far out. For now I'll watch this over time (no pun here !) and manually adjust accordingly with date -a.

Our Progress database is to run QAD's MFG/PRO ERP application, which basically our whole business depends on.

All the best.

Rob.