EXE$GL_ABSTIM_TICS questions.

[Roger tucker_1]

The problem is: how to determine the real elapsed time (wall-clock time) between any two events. Sounds simple, but if you think about it a little bit – it’s not. If you use sys$gettim() for the start of the event and compute the difference with another sys$gettim(), or use unix time routines, or any other routines that return something dependent on the system clock - the system clock could change or be adjusted during the event and you would compute the wrong elapsed time. So, I wondered how does VMS do this internally since quantum end is a specific elapsed time and there are other wait states in VMS that don't depend on the system clock. I came across EXE$GL_ABSTIM_TICS which contains the number of 10-millisecond intervals that have elapsed since the system was bootstrapped. Perfect and works great. The problem is, it rolls over every 497.1 days and handling the wrap is complex since I have a time ordered list of events that I’m messing with. We normally boot a few times a year, but just in case I would like to see this field be changed to a quadword. There are also several other undocumented fields EXE$GL_ABSTIM_UTICS for example. Any other ideas on how to do very small (10-millisecond) time deltas not dependent on the system clock?

[John Gillings]

Roger,

This is one of those places where OpenVMS is constrained by its fanatical adherance to upwards compatibility. Many things would be significantly simpler if EXE$GL_ABSTIM_TICS were made into a quadword. There have been endless debates about it, both during the Alpha port and more recently the IA64 port. Upshot is, it's not going to change! (sorry).

There seem to be two issues here - one is keeping track of very long time intervals (years?) and the other is small deltas. There is no single clock which does both jobs well.

For long time periods your best bet is to use UTC. This should compensate for any daylight savings adjustments. Yes the clock might be adjusted to keep it accurate, but from the relativistic perspective of the process, there is no way, even in theory, to deal with such shifts in frame of reference. I think you need to assume the clock is kept in synch with a standard time source and any such adjustements can only make your UTC calculation more accurate.

For very short intervals at high resolution there is the PCC (Process Cycle Counter), but it only measures CPU time consumed by the process, and it wraps fairly frequently. There is also the SCC (System Cycle Counter), this counts total CPU cycles in a 64 bit counter, but there is one per CPU, CPUs can be started and stopped and (maybe one day) might even be different speeds, so keeping track can be a bit tricky. You'll need an architecture manual and source listings to work out if they're of any use to you.

[Cass Witkowski · Accepted solution]

Why not add a new memory location that is a quadword EXE$GQ_ABSTIM_TICS in addition to the current long word EXE$GL_ABSTIM_TICS. The routine that increments EXE$GL_ABSTIM_TICS could be modified to also increment the quadword location as well.

This way people could have a choice to continue to use the old location or the new one.

It the same token the system could start keeping time in UTC as well as the local time in the current locations.

[Jan van den Ende]

Cass,

I second those ideas!

If it is a little bit feasable (and why shouldn't it?) then that would be great (for us, UTC would be the higer value, but YMMV)

Proost.

Have one on me (maybe at the Bootcamp in Nashua?)

jpe

[Richard J Maher]

Hi Roger,

If you're related to Roger "T"ucker then could you please take a couple of minutes to revisit one of your last questions: -

http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=985905

Please, I'm not after the points (go crazy with zero), I'm genuinely interested in what you are doing and if any progress has been made.

Regards Richard Maher

[Roger tucker_1]

Richard,

Yes, I'm the same person. I tried many times to login to this account, but was never successful. I think it had to do with our e-mail addresses changing when our company sold and the old e-mail address were disabled, so I can't have the ITRC send me a new password, or assign points... (If there is someone from ITRC that could combine the account with this one, I would appreciate it; but if not - no big deal.)

I've been busy working on other things, so no progress has been made in this area. (I normally do my homework and rarely ask questions that have good answers anyway. :-) When I get back to this (maybe in a year or so), I was going to just jump to kernel mode and do my own stuff. User mode read for performance and exec mode or super mode write to protect the section.

Hi Roger,

If you're related to Roger "T"ucker then could you please take a couple of minutes to revisit one of your last questions: -

http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=985905

Please, I'm not after the points (go crazy with zero), I'm genuinely interested in what you are doing and if any progress has been made.

Regards Richard Maher