Time flies, but it can still be measured

Time Out

Article from ADMIN 12/2012

By Federico Lucifredi

This month, we examine a Unix system's stopwatch options.

Run time is a most convenient, simple benchmark, and it is very often the metric for which you will be asked to optimize – making things faster being the default objective in our world.

As it turns out, you will hardly ever need an external timekeeping device; the internal system facilities are more than adequate for anything happening in user space.

At its most basic, the omnipresent time Bash built-in command provides a breakdown of where a program's share of CPU was spent and how much time elapsed during a given task:

$ time ps -axjf > /dev/null
real    0m0.029s
user    0m0.005s
sys     0m0.019s

The process listing took about 3/100 of a second to execute in the real world and was allocated 5/1,000 of a second of CPU time in kernel mode (i.e., executing system calls) and about 2/100 of a second in user space. That the sum of kernel time and user time rarely corresponds to real time elapsed should not surprise you because you know that the process examined was not the only one being scheduled on the CPU. What might surprise you is that the execution time of multithreaded processes can exceed wall clock time, in the case of multicore processors. For example, in Listing 1, execution time is nearly doubled compared with wall clock time for the stress [1] benchmark, but time travel was not required – merely a dual-core Intel Core 2 processor.

Listing 1

Stress Test Execution Time

$ /usr/bin/time stress --cpu 2 -t 1
stress: info: [10050] dispatching hogs: 2 cpu, 0 io, 0 vm, 0 hdd
stress: info: [10050] successful run completed in 1s
        1.00 real         1.81 user         0.00 sys

Attentive readers will have noticed

...

Use Express-Checkout link below to read the full article (PDF).