DCPI FAQs

»

DCPI

Site information

» Send us your comments

Installation

» Download DCPI
» Installing DCPI

Product information

» Frequently asked questions
» Documentation
» Publications
customer times newsletter link
Q. What are "unknown" samples?

What are the causes of unknown samples?

How can unknown samples be identified?

A. The dcpid daemon will classify a sample as unknown when it cannot be associated with any known executable image (such as an application, shared library, or kernel module). The mapping of samples to images has improved with each release of dcpid, but there are still some situations that will result in unknown samples. In most cases, the total number of unknown samples will be negligible. If a large number of samples (e.g., significantly more than 1%) are classified as unknown, it may be due to one of the following reasons:
  • On DIGITAL Unix, processes that are created by programs that fork(2) without subsequently invoking exec(2). A recent enhancement to dcpid helps classify such samples, at least for relatively long-lived processes. See the -forkid option described in the dcpid man page for additional information.
  • Execution of dynamically-generated code, such as code emitted at runtime by "just-in-time" (JIT) compilers. Samples in such code cannot be attributed to an executable image without manual intervention. In many cases, there is no non-volatile executable image with which to associate samples. See the register option described in the dcpictl man page for additional information.
  • An internal buffer overflow. When processes are created at an exceptionally high rate, it is possible for a kernel image name translation buffer to overflow. Check the dcpid log file for messages of the form dcpid: pcount: dropped N image name translations.

By default, unknown samples are aggregated by event type, and a single count is stored for each event in a profile named with the prefix unknown@host, where host is the local machine name. The -unknown option to dcpid can be used to help help identify the source of unknown samples. When this option is used, unknown samples are stored in separate profiles associated with 1MB regions of each process address space. The resulting profiles are given names with the prefix hostPID@address, where host is the local machine name, PID is the process identifier associated with the sample, and address is the starting address for the region containing the sample. In some cases, this information will make it possible to manually identify the source of the unknown samples.

Q. Why can't I run dcpid at the same time as other tools such as uprofile, kprofile, and iprobe? A. All of these tools use the Alpha hardware performance counters, but each requires exclusive control of the counters and use different device drivers to access them.
Q. How can I obtain SCL? A. SCL is currently available by download from this web site. You will need to agree to the license terms and register your details in order to obtain the software.

In the future SCL may be packaged with other developer tools for Tru64 UNIX
Q. dcpiflow, dcpicalc 

Why does dcpiflow or dcpicalc say "could not compute jump table targets"?

A. This error message means that the program could not automatically determine all of the targets of a computed jump instruction. See the documentation for dcpicalc to find out how to fix this problem. (Note: dcpiflow has been subsumed into dcpicalc.)
Q. dcpisource

Why do I get the error message "dcpisource: perl not found"?

A. You need to have perl installed on your system in order to run dcpisource. Perl source code is available on the web.
Q. dcpiprof 

Why do dcpiprof and dcpicalc disagree on stall information?

A. Dcpiprof just lists the number of event samples accrued per procedure for each event type monitored by dcpid. Dcpicalc uses a detailed machine module to compute actual number of stall cycles attributable to a given machine event. Therefore, when dcpiprof lists 17% imiss, it means that 17% of the imiss samples in dcpiprof's output fell within a particular procedure. When dcpicalc gives a percentage for "I-cache" activity, it means that that percent of all cycles spent in this procedure were attributable to i-cache misses.
Q. dcpicalc, dcpiwhatcg 

What does "unexplained gain" mean?

Why is it negative?

Is it ever possible to see "over-100%" execution?

A. Unexplained gain occurs at places in the code where instructions take fewer cycles to execute than even our ideal assumption suggests. For example, our analysis assumes that an Alpha~21164 processor ideally can issue 2 instructions in each cycle. If in fact 3 instructions are issued, 0.5 cycle would be attributed to unexplained gain, since 3 instructions are expected to take at least 1.5 cycles. This scenario is possible because the processor can actually issue 2 instructions to the integer pipeline and 2 to the floating-point pipeline every cycle. (Assuming quad-issue as the ideal case would leave all integer code with under-50% execution. This may confuse many users, as would using different assumptions under different circumstances.) If this occurs consistently enough throughout the code being analyzed, the percentage of cycles spent on instruction execution can exceed 100%, which is sometimes the case for code with many floating-point operations.

Unexplained gain is shown as a negative number because all other numbers in the same table represent cycles that are in some sense "lost" (e.g., to D-cache misses) or "spent" (e.g., on executing instructions). These positive numbers and the unexplained gain always add up to 100%, with the gain shown as negative to indicate that its contribution to the sum is in a direction opposite that of the others.

For more details, see "INTERPRETING OUTPUT" in the man page for dcpicalc.

Q. Tru64 UNIX specific questions

Why does dcpid not produce any profiles?

Why does the entire system hang when dcpid is running?

A. A kernel bug exists in Tru64 UNIX that can occasionally cause dcpid to crash, and can even crash the kernel in rare cases. Running dcpid with the -b flag prevents dcpid from doing its initial scan of the system process tables and hence from triggering the bug. Note that this will also prevent dcpid from determining what images are loaded in processes that are already running when it starts up.

Unlike earlier versions of dcpid, which performed frequent scans of system tables to identify statically linked executables, the current version only performs a single scan during initialization. Thus, it is extremely unlikely that this problem will be encountered. It is generally worth the risk of performing the initial scan in order to obtain useful information about the processes that were already executing when dcpid was started.