How Quantify times system calls

When your program requests an operating system service such as reading from or writing to a file, it executes a system call. Each system call switches the processor from user state to kernel state, permitting the operating system to process the request. When the request is complete, the operating system switches the processor back to user state and returns control to your program.

Quantify measures the time required to execute each system call. You can choose to measure this time in elapsed (wall-clock) or kernel time. For more information, read Controlling how system calls are timed. Quantify converts the measured time to machine cycles based on your processor's clock speed, then assigns the cycles to the function containing the system call.

System call times help you to see how much time your program spends waiting for operating system requests and the variation in your program's performance due to load fluctuations on your machine and the network. On an unloaded machine, system calls that do not involve access to other devices, such as disk drives and ethernet controllers, typically execute in nearly constant time. The time required to access remotely mounted file systems through NFS or to make requests to the X Windows server can vary depending upon the remote machines, the server process, and the network.

You can use Quantify options and API functions to customize timing for system calls. For more information, read Timing system calls.

By default, Quantify does not time system calls such as select because they rely on unpredictable events such as a user clicking a menu item.

For the system calls that Quantify does not time by default, click

For the Solaris system calls associated with lightweight processes that Quantify does not time, click  

You can have Quantify report the excluded system call times. For more information, read Reporting excluded system-call time.

Variations in system-call timing

Timing system calls can produce widely varying measurements of program performance, especially over short runs. The recorded information depends on the machine state, the contents of memory, the other processes running on the machine, the load on the network, and so on. This is to be expected and can be the very effect you want to demonstrate.

Quantify uses the gettimeofday or getrusage system call to time system calls, discounting the small amount of time these calls take. Depending on the other processes that have made system requests, the kernel can switch context during Quantify's request for gettimeofday. If this occurs after the system call Quantify is timing, the measured time appears longer than it actually was.   

Quantify does not adjust for this effect, since it cannot detect that it has occurred. In most programs, however, this happens infrequently.