[Search for users]
[Overall Top Noters]
[List of all Conferences]
[Download this site]
Title: | Alpha Support Conference |
Notice: | This is a new Alphanotes, please read note 2.2 |
Moderator: | VAXAXP::BERNARDO |
|
Created: | Thu Jan 02 1997 |
Last Modified: | Fri Jun 06 1997 |
Last Successful Update: | Fri Jun 06 1997 |
Number of topics: | 128 |
Total number of notes: | 617 |
49.0. "OpenVMS AXP CPU tick" by HGOVC::STEVENCHEUNG () Fri Feb 21 1997 01:14
Dear ALL,
Lately I have a client who decided to re-write one of
the macro programs of accessing the CPU null time
using Pascal under the Alpha Migration project.
In the process of testing, errors was discovered that
one of the displaying function of the CPU utilization
is never/rarely displayed on AXP platform. In fact,
however, the same code is working on the VAX side.
The original macro program was written to access
the primary CPU data block using a pointer named
SMP$GL_CPU_DATA. Having located the primary CPU
data block, another offset named CPU$Q_NULLCPU
is used to access the null ( idle ) time recorded
for this primary CPU. In VAX side, the time was
measured in 10-millisecond, however, on the Alpha
platform, this was not the same case because the
customer had written a Pascal program to access the
SMP$GL_CPU_DATA data block directly. The values
obtained through tracing through the pascal program
showed the values obtained by many calls to the
CPU$Q_NULLCPU of each CPU data block, the figures
are much bigger than what was expected on the VAX
side. The unit of time used for this direct access
may not be measured in 10-millisecond on the AXP
platform.
My question at this point is :
What is the unit used in this CPU$Q_NULLCPU of this
CPU data block ? Is the measurement still in
10-millisecond unit or much smaller ?
Please respond if you have any idea because this is
rather crucial at this stage when the whole Migration
can be completed with the correct displaying under the
performance and integrity testing which are underway
before the customer can announce the launch date.
It would mean the customer will start buying Alpha
in tons and be the base of every system from now
on and with years to come.
steve
T.R | Title | User | Personal Name | Date | Lines |
---|
49.1 | answered by mail =1024 hertz | CERN::HOBBS | Congrats to the Ignoble Peace Prize winner! (http://www.eecs.harvard.edu/ig_nobel) | Fri Feb 21 1997 04:28 | 0 |
49.2 | EXE$GETSPI | XDELTA::HOFFMAN | Steve, OpenVMS Engineering | Fri Feb 21 1997 09:15 | 5 |
|
See the *GETSPI* keyword over in NOTED::HACKERS for a program that
allows a user-mode program to retrieve null time using (undocumented)
calls underneath MONITOR.
|
49.3 | How $GETSPI does it | EVMS::DAVIDB::DMILLER | This bug fix broke what??????? | Fri Feb 21 1997 13:02 | 5 |
| The size of a tick is not constant. Newer Alphas may use a different
clock rate. Instead of hardcoding 1024, use the contents of the system
cell EXE$GL_SYSTICK, which is the size of a clock tick in 100ns units.
-Dave
|
49.4 | Get a copy of the IDSM.... | STAR::CROLL | | Mon Feb 24 1997 10:21 | 5 |
| If this customer spends any time with privileged code, he or she should get a
copy of the Internals and Data Structures manual. A few minutes in chapter 12
would have answered this question easily.
John
|