Is there a set of patches around for linux kernel that address accuracy of (system, rather than user) process time?

i've heard about RTLinux, but i don't really need the actual real-time scheduling constraints, i just need that the time measurements are accurate. If the process switch slipped by a couple milliseconds, so be it, but i need an accurate measurement of the actual time spent in the current process


If what you have in mind is the usage of time shell builtin, then 3 digit precision is the design limitation - as per man bash:

          The value of this parameter is used as a format string  specify‐
          ing  how  the timing information for pipelines prefixed with the
          time reserved word should be displayed.  The % character  intro‐
          duces  an  escape  sequence  that is expanded to a time value or
          other information.  The escape sequences and their meanings  are
          as follows; the braces denote optional portions.
          %%        A literal %.
          %[p][l]R  The elapsed time in seconds.
          %[p][l]U  The number of CPU seconds spent in user mode.
          %[p][l]S  The number of CPU seconds spent in system mode.
          %P        The CPU percentage, computed as (%U + %S) / %R.

          The  optional  p is a digit specifying the precision, the number
          of fractional digits after a decimal point.  A value of 0 causes
          no decimal point or fraction to be output.  At most three places
          after the decimal point may be specified; values  of  p  greater
          than  3 are changed to 3.  If p is not specified, the value 3 is

For seemingly more precise measurements, you can try using date with customized output formatting to show nanoseconds:

Tstart=$(date "+%s.%N")
Tend=$(date "+%s.%N")
echo "Elapsed: $( Tend-Tstart |bc -l) nanoseconds"

However, notice that in both cases (time and date), you have some overhead, as the system takes some time to run the starting/stopping commands. The overhead is smaller for time, thanks to it being a builtin. So the three-digit limit is there for a reason: the rest is just random garbage.

See also this similar question, though the accepted answer contains a little bug currently.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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