Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have a script converting video files and I run it at server on test data and measure its time by time. In result I saw:

real    2m48.326s
user    6m57.498s
sys     0m3.120s

Why real time is that much lower than user time? Does this have any connection with multithreading? Or what else?

Edit: And I think that script was running circa 2m48s

share|improve this question
re your EDIT - that makes perfect sense, since real time is wall-clock time as explained below (ie what we would measure if we had a stop-watch) – Levon Jun 13 '12 at 17:39
up vote 12 down vote accepted

The output you show is a bit odd, since real time would usually be bigger than the other two.

  • Real time is wall clock time. (what we could measure with a stopwatch)
  • User time is the amount of time spend in user-mode within the process
  • Sys is the CPU time spend in the kernel within the process.

So I suppose if the work was done by several processors concurrently, the CPU time would be higher than the elapsed wall clock time.

Was this a concurrent/multi-threaded/parallel type of application?

Just as an example, this is what I get on my Linux system when I issue the time find . command. As expected the elapsed real time is much larger than the others on this single user/single core process.

real    0m5.231s
user    0m0.072s
sys     0m0.088s

The rule of thumb is:

  • real < user: The process is CPU bound and takes advantage of parallel execution on multiple cores/CPUs.
  • real ≈ user: The process is CPU bound and takes no advantage of parallel exeuction.
  • real > user: The process is I/O bound. Execution on multiple cores would be of little to no advantage.
share|improve this answer
I don't know if avconv is multi-threaded. May it be. avconv is the new generation of ffmpeg. I was converting 7 short flv files (about 20 seconds each). – kobylecki Jun 13 '12 at 15:59
real time would usually be bigger than the other two - but I ask about other situation – kobylecki Jun 13 '12 at 16:17
This explanation is correct. It looks like this process was run on 4 cores. See also my explanation of hyperthreading for more on how real/sys/user time is calculated. It doesn't relate exactly, but the concepts are the same. – bahamat Jun 13 '12 at 16:32
@kobylecki real time is less than the others because it looks like avconv is run on multiple cores. Since I don't know that software, nor how it was run, I don't want to make a 100% claim, but this is what it looks like based on the available information (3 lines of time measurements, and knowledge :-) – Levon Jun 13 '12 at 17:36
In the find example usr value is much lower because most of the time has been spent during interrupts, even if find would have been multithreaded it would have stayed low (sorry if I don't master english tenses). – Emmanuel Oct 7 '13 at 12:07

Just to illustrate what has been said, with a two threaded processes doing some calculation.

    #include <pthread.h>
    static void  * dosomething () {
        unsigned long a,b=1;
        for (a=1000000000; a>0; a--) b*=3;
        return NULL;
    main () {
        pthread_t one, two;
        pthread_create(&one,NULL, dosomething, NULL);
        pthread_create(&two,NULL, dosomething, NULL);
        pthread_join (one, NULL);
        pthread_join (two, NULL);
/* end of a.c */


gcc a.c -lpthread

(This is just to illustrate, in real life I should have added the -D_REENTRANT flag)

$ time ./a.out

real    0m7.415s
user    0m13.105s
sys     0m0.032s

(Times are on an Intel Atom that has two slow cores :) )

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.