From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 1164f8,b3c24209310418d0 X-Google-Attributes: gid1164f8,public X-Google-Thread: fee84,b3c24209310418d0 X-Google-Attributes: gidfee84,public X-Google-Thread: 103376,b3c24209310418d0 X-Google-Attributes: gid103376,public From: dccoote@werple.mira.net.au (David Coote) Subject: Re: Timing Ada programs using the DEC UNIX microtimer kernel option Date: 1998/04/26 Message-ID: <6hu5lv$l8u$1@eplet.mira.net.au>#1/1 X-Deja-AN: 347711218 References: <6hsab5$rh1$1@eplet.mira.net.au> <6hu3hr$8v4$1@nntp.Stanford.EDU> Mime-Version: 1.0 Content-Type: Text/Plain; charset=US-ASCII Organization: werple public-access Internet Newsgroups: comp.unix.osf.osf1,comp.sys.dec,comp.lang.ada Date: 1998-04-26T00:00:00+00:00 List-Id: [snipped lots of useful stuff.] >But all Alphas have a high-resolution CPU cycle-counter, or an I/O bus >cycle-counter to get usec or better resolution. As well as that, >there's usually either a PC-compatible timer chip or a cycle-counter >on the I/O bus. If you find the CPu clock speed (e.g., via busy-loop >counting cycles between clockticks early in boot) it's easy to >interpolate from any of these to usec or 10s of nanosec resolution. > >For uniprocessors (like the machines here), you can use CPU cycles >directly. Multiprocessors require more care to keep the per-CPU >cycle-counter value at each realtime clock tick, or the process' clock >values jump around when context-switching from one CPU to another. Or >you can just use a lower-resolution, but shared, IO bus cycle counter. You can use the rpcc assembler instruction to access the on-chip cycle counter. But as you say above there is a problem here with processes swapping CPUs on a multi-CPU machine and hence accessing different PCC registers. You can use the runon command to ensure a process stays on a CPU but then you're interfering with the kernel scheduling algorithm. For this reason our customer stuck a requirement in the SRS that specifically forbids using the runon command in the production system. > >I seem to recall Dave Mills saying that DEC gave him some hardware >precisely to get NTP and precision timekeeping correct. >It would be rather odd if DU still doesnt get this right. I asked DEC USA support if they could give us overhead and resolution figures for timing system calls. They recommended that we benchmark these ourselves as they don't have anything recent. I asked if DEC could add a system call to the OS to give in one system call the CPU utilisation figure (defining CPU utilisation as percentage of CPU time divided by elapsed time) of low overhead and accuracy/resolution below 1ms, perhaps using the PCC register. (The total number of cycles used by a process is preserved on multi-CPU machines when a process swaps CPUs.) They indicated that this could be done but I'm still waiting :(