- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- Precision Timekeeping
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-25-2008 12:03 PM
тАО07-25-2008 12:03 PM
Precision Timekeeping
I have a question on precision timekeeping. The following is recommended. I found that if I want to use it to meassure rather long time, scc2 - scc1 will be negative or a very large number, which is not useful. Is there a way to work it around while still keeping the high resolution?
#include
#include
#include
#include
#include
#define QUOTE(s) #s
#define QUOTEVAL(s) QUOTE (s)
#define RSCC() (asm ("call_pal " QUOTEVAL (EVX$PAL_RSCC)))
extern HWRPB* exe$gpq_hwrpb; /* Hardware Restart Parameter Block */
int main( int argc, char** argv )
{
__int64 scc1, scc2, micro;
scc1 = RSCC();
sleep (3);
scc2 = RSCC();
/*
// The number of ticks per second is located in the Hardware
// Restart Parameter Block (HWRPB). Convert it to microseconds.
*/
micro = (1000000 * (scc2 - scc1)) /
exe$gpq_hwrpb->hwrpb$iq_cycle_count_freq;
printf ("%Ld microseconds\n", micro);
}
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-25-2008 01:01 PM
тАО07-25-2008 01:01 PM
Re: Precision Timekeeping
but the cycle counter is cpu specific.
How are you ensuring the process is still on thesame cpu? when measuring "a rather long time", could it not easily have been rescheduled on an other cpu?
see also
http://h71000.www7.hp.com/wizard/wiz_8572.html
hth,
Hein.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-25-2008 04:35 PM
тАО07-25-2008 04:35 PM
Re: Precision Timekeeping
And then there's the question of the required precision for your accurate answer. Various OpenVMS APIs can deceptively return high precision values, but with relatively low accuracy.
Then there are the potential alternatives, such as the available ANALYZE /SYSTEM (SDA) tools used to look at PC values other such activities.
Gag. I'm giving the same answer.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-25-2008 05:02 PM
тАО07-25-2008 05:02 PM
Re: Precision Timekeeping
In addition to Hein's comment about switching to a different CPU, consider that it could be on the same CPU, but have been preempted an arbitrary number of times for an arbitrary amount of time.
One much be very careful that the semantics of what one is doing match those desired.
- Bob Gezelter, http://www.rlgsc.com
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-25-2008 05:31 PM
тАО07-25-2008 05:31 PM
Re: Precision Timekeeping
What problem are you trying to solve? What are you measuring that requires high precision (resolution)?
It appears that the example code you provided came from the "ask the wizard" article Hein referenced. Did you read and understand the text that went along with it? Specifically the part about SMP.
The PCC_CNT register is only 32 bits wide, and is updated by hardware. It takes just over 4 seconds to wrap around on an implantation that updates it once every nanosecond. The interrupt service routine updates the high 32 bits of the unsigned 64 bit value that is returned by CALL_PAL RSSC.
If you are getting a negative value from the subtraction, that implies either that subtraction isn't 64 bits wide, or that you are comparing values obtained from different processors. It takes a long time (If I did the math right, over 584 years, over 292 years if treated as signed) to cause a 64bit resister to overflow, if it is incremented once every nanosecond (1*10^-9 sec) So I don't believe it overflowed.
Jon
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-25-2008 06:06 PM
тАО07-25-2008 06:06 PM
Re: Precision Timekeeping
You can download the Alpha Architecture Manual in PDF format. (Currently available from http://download.majix.org/dec/alpha_arch_ref.pdf)
Here's what the Architecture Manual states:
See what note 3 says. If the SCC looses ticks, interrupts have to be disabled at or above CLOCK_IPL interrupt level for an extended period of time. That is going to be noticeable.
Following from Section II-A OpenVMS Software, pages 10-16 and 10-17.
10.1.12 Read System Cycle Counter
Format:
Operation:
R0 <- {System Cycle Counter}
Exceptions:
Instruction mnemonics:
Description:
The RSCC instruction writes register R0 with the value of the system cycle counter. This
counter is an unsigned 64-bit integer that increments at the same rate as the process cycle
counter. The cycle counter frequency, which is the number of times the system cycle counter
gets incremented per second rounded to a 64-bit integer, is given in the HWRPB (see Section
26.1).
The system cycle counter is suitable for timing a general range of intervals to within 10% error
and may be used for detailed performance characterization. It is required on all implementations.
SCC is required for every processor, and each processor in a multiprocessor system has
its own private, independent SCC.
Notes:
1. Processor initialization starts the SCC at 0.
2. SCC is monotonically increasing. On the same processor, the values returned by two
successive reads of SCC must either be equal or the value of the second must be greater
(unsigned) than the first.
3. SCC ticks are never lost so long as the SCC is accessed at least once per each PCC
overflow period (2**32 PCC increments) during periods when the hardware clock
interrupt remains blocked. The hardware clock interrupt is blocked whenever the IPL is
at or above CLOCK_IPL or whenever the processor enters console I/O mode from program
I/O mode.
4. The 64-bit SCC may be constructed from the 32-bit PCC hardware counter and a 32-bit
PALcode software counter. As part of the hardware clock interrupt processing, PALcode
increments the software counter whenever a PCC wrap is detected. Thus, SCC
ticks may be lost only when PALcode fails to detect PCC wraps. In a machine where
the PCC is incremented at a 1 ns rate, this may occur when hardware clock interrupts
are blocked for greater than 4 seconds.
5. An implementation-dependent mechanism must exist so that, when enabled, it causes
the RSCC instruction, as implemented by standard PALcode, always to return a zero in
R0. This mechanism must be usable by privileged system software. A similar mechanism
must exist for RPCC. Implementations are allowed to have only a single mechanism,
which when enabled causes both RSCC and RPCC to return zero.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-26-2008 04:10 AM
тАО07-26-2008 04:10 AM
Re: Precision Timekeeping
Jur.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-28-2008 12:14 PM
тАО07-28-2008 12:14 PM
Re: Precision Timekeeping
Thanks,
YE LIU
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-28-2008 01:19 PM
тАО07-28-2008 01:19 PM
Re: Precision Timekeeping
Jur.