Read RTC on 11i

[Takanori Ikuta_1]

Hi.

Could you tell me how to read RTC on 11i?
Or is it impossible?

Thanks.

[Karthik S S]

Do you mean Real Time Clock?? Date command will show you the RTC.

-Karthik S S

[Rajeev Shukla]

Date command reads the RTC and displays the formated output.
Have a look at man pages of date and you'll see ctime() time() and other functions if you want to read the RTC in C.

[Takanori Ikuta_1]

Sorry.

I had been thinking that RTC(Real Time Clock) is the hardware clock and the OS time(System time) is the software clock.

Dose date command read the hardware clock and display?

If date command reads not the hardware clock but the software clock,how to read the hardware clock on 11i?

Thanks.

[Elmar P. Kolkman]

Date will read the OS clock, not the RTC. Your right about that. When the system starts, the RTC is copied to the OS (or system) clock.
Some HP-UX systems allow the RTC to be read or written from the OS, but not all (for instance on the N-class systems, the RTC can only be changed from the BCH).

I'm sorry I don't know the commands.

[Dietmar Konermann]

There is no official way do access the "RTC" (aka TOD, time of day) directly. Essentially there's no need to try it. Let me try to explain...

The TOD's resolution is only 1 second... and it's read by the OS during bootup for inittializing the OS's "software clock".

Later on only this one is used for syscalls like time(2) or gettimeofday(2). Its speed is derived from the system's central clock speed... so the resoluton is _much_ higher than only 1 second.

If you change the time, e.g. using date(1) - which calls stime(2) - then the TOD is also updated. This also done in regular intervals to keep the clocks in sync.

Best regards...
Dietmar.

[Elmar P. Kolkman]

I'm sorry to disagree, but the RTC is not updated on all HP-UX systems. For instance, the N-class systems will not overwrite the RTC from the OS. This was a problem I had questions about in the past and was only solvable from the BCH.

[Dietmar Konermann]

Elmar,

I see the PDC calls that are supposed to update the RTC in the kernel source (just checked 11.00 and 11.11).

So at least HP-UX attempts to do it. :-)

Maybe your N-Class ignored the requests due to some Hardware/Firmware problem? I just tested on one of our N-Classes... worked fine as expected.

Best regards...
Dietmar.

[Elmar P. Kolkman]

Dietmar,

Could you be more specific about how you tested these calls?

I had this thread: http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=238206

If I can set the RTC/hardware clock with those calls, it might solve this thread too.

Elmar

[Dietmar Konermann]

Elmar,

I didn't test these PDC calls directly. I simply used the date(1) command to change the time and then halted the machine. Then I checked the RTC from BCH (COnfiguration Menu, TIme)... and my change was visible, even after powercycling the system.

BTW, the time initialization during bootup is a little bit tricky. Maybe this can explane what you've seen?

The kernel gets two times...

1) the time from the RTC
2) the f_time of the boot file system, which is usually the umount time of /stand.

Now the following rules apply:

1) RTC - f_time <= 0:
RTC = f_time; newtime = f_time;

2) 0 < RTC - f_time < 60*60*24*365 (1 year):
newtime = RTC;

3) RTC - f_time >= 60*60*24*365
RTC = f_time; newtime = f_time;

Hope that helps...
Dietmar.

[Takanori Ikuta_1]

Dietmar,

First of all, the reason of my question is that I want to investigate when the system clock will be copied to the RTC in a vPars environment.

In non-vPars environment,I think that the system clock(or unmount time of /stand?) is copied to the RTC when the system has been shut down.

Then,when is the system clock copied to the RTC in a vPars environment?

I guess that the system clock of the vpar which has been shut down at last is copied to the RTC.And then the drifts relative to the RTC is modified on the basis of that vpar.

Do you know about this?

Thanks.

[Elmar P. Kolkman]

On our server(s) we saw the following:
after boot the server was 6 hours off. So we set the clock to the correct time (it was 6 hours in the past, so we needed to set the clock forward). After the next reboot, same problem, and again another time, always the same server, always the same problem. So in our case the RTC was NOT set with the date and ntpdate commands.

So, I posted on the ITRC and logged a call at HP. Result is what you can read in my post: on this class of servers, the RTC is not updated from the OS, only from the BCH. So we set the clock right using that. The person doing this forgot that it needed to be in UTC, so the RTC is still one hour off, but at least that's closer then the 6 hours we had. We are planning to solve this 'little' issue in a next reboot. But at least we have a solution.

Perhaps the reason this doesn't work has to do with the fact that this machine can support partitioning (though we are not using it)... There is no rule I know off that says the system clock has to be the same on all partitions. Since there was no one on the ITRC knowing of this problem when I asked, perhaps you should ask the question to your HP representive. And post the result of that so we all can learn from it, of course.

[Dietmar Konermann]

Hello Takanori San,

the situation in vPAR environments is different. The OS also attempts to update the RTC using the usual PDC_TOD_SET call... but here we are running in a virtual machine where vpmon emulates the PDC. The real RTC is never updated in this case. The vpmon only stores the difference in its vpdb and never changes the RTC.

See vPAR Manual http://docs.hp.com/hpux/pdf/T1335-90018.pdf on page 30 for details.

Elmar, once again, the OS always ATTEMPTS to update the RTC using PDC_TOD_SET. If this does not work then the underlying PDC layers are responsible for that. Unless you are in a vPAR this is firmware/hardware stuff. (On our N-Class this works fine as I noted above.)

Best regards...
Dietmar.

BTW, on systems that support hard partitions (nPAR), we have a RTC on each cell board. Here the partitions core cell board RTC is used. (And it's also supposed to be updated.)

[Takanori Ikuta_1]

Hi,Dietmar.

Thank you for your response.

I read that manual and understand about the detail of the RTC.
But I can not be convinced about that manual.
If it is right, I cannot understand the following case.

Environment.
Systen Hardware:rp7410
OS version:HP-UX 11i ver1.0
Product:VPARBASE(A.02.02)

Problem case.
1.Boot npar.
2.Set the RTC exactly on BCH.
3.Load ISL from vpar0's.
4.ISL>hpux /stand/vpmon
5.MON>toddriftreset
6.MON>vparload -all
7.vpar0 and vpar1 was loaded.
8.Date command show me exactly time on each vpars.
9.Set forward the OS time on vpar1 for 10 minutes.
10.Wait more five minutes for syncing from mastar copy of /stand/vpdb on memory to local copy of /stand/vpdb on each vpar's disk.
11.Shut down vpar0.(execute "shutdown -h -y 0" on vpar0)
12.Shut down vpar1.(execute "shutdown -h -y 0" on vpar1)
13.MON>reboot
14.After rebooted,checking the RTC on BCH.
15.The RTC is 10 minutes fast from exact time.

->This means that the RTC on BCH is updated!!

So my question is the following.
1.When is the drifts relative to the RTC modifyied?
I guess that it is modified when the OS time is updated by using date command and when the vpar has shut down.
2.When is the master copy of vpdb on memory synced to the local copy of vpdb on the disk.
I guess the timing of that the following case.
a.every 5 minutes.
b.vpard is loaded.
3.When is the RTC modified?
I guess that it is modified when the HP-UX on vpar has shut down.
4.Can I manage vPars which have diffrent TOD?
I don't know...

Thanks.

[Dietmar Konermann · Accepted solution]

You are right, I missed the fact that vpmon maintains the "most future" time of all vpars in TOD. But an independet drift for each vpar is stored in vpdb, ensuring that each vpar can have its independent time.

According to your questions...

1) When the OS sets the TOD, then this vpar's drift is modified. This happens on 11.11 every 10 minutes and when the software time is adjusted.

2) This is done every 5 seconds (not minutes).

3) The vpmon keeps the RTC not to be behind any vpar. The drifts are recalculated accordingly.

4) Of course. Don't mind about the TOD/RTC and you're done.

Best regards...
Dietmar.

[Takanori Ikuta_1]

Dietmar.

Japanese Edition Manual says that the master copy is synced to the local copy on each vpar's disk every 5 minutes.
I think so.
Because of the timestamp of /stand/vpdb on each vpar's disk(display by "ls -l" command) is updated every 5 minutes.

Which is right?

P.S.Our vPars product is VPARBASE(A.02.02)

[Dietmar Konermann]

Hello Takanori San,

The vpard by default checks every 5 seconds, if the on-disk copy is older than vpmon's master copy in memory. Then the vpdb is only written out if needed. The interval can be changed using vpard's -i option (takes the sleep time in seconds).

Best regards...
Dietmar.

[Takanori Ikuta_1]

Hi,Dietmar.

Thank you very much for your useful information.
I feel easy and sleep at last. :-)

Doumo Arigatou Gozaimasita!!

Takanori Ikuta