3

I do some local experiments on different database systems. I collect (sum up) CPU information from /proc/status before and after I execute a query. The difference should tell me the amount of jiffies or USER_HZ during query runtime. But the difference is zero when (according to clock_gettime()) a query has a runtime somewhere below 0.001 seconds. Is this to fast to utilize the CPU information or am I missing something else?

Barton Chittenden
  • 4,238
  • 2
  • 27
  • 46
lupz
  • 3,620
  • 2
  • 27
  • 43
  • `clock_gettime` has nanosecond resolution on most machines, or at least microsecond. I use it all the time for measuring time and never get zero. – edA-qa mort-ora-y May 01 '12 at 07:14

1 Answers1

1

A jiffy, as of Linux kernel 2.6.0, is 1/250 of a second, or 0.004 seconds [see time(7)]. You'll never get a smaller resolution than that.

I recommend you use the rdtsc instruction, which is likely available as a compiler intrinsic. This is incremented every 1 CPU tick, so by dividing by the frequency you can get the amount of time that passed. You can also implement it with inline assembly.

It's actually a bit ridiculous to be checking /proc/status because there's a good chance that opening the file descriptor and reading the contents will actually take longer than your query did to execute. rdtsc is much more reliable.

Mahmoud Al-Qudsi
  • 28,357
  • 12
  • 85
  • 125
  • Thank you for clarifying this. Usually my queries run some orders of magnitude longer. So I hope the access overhead to `/proc` can be ignored for a sufficient approximation of cpu utilization. I'll take this as an evaluation of my measuring process: it does not even take a jiffy :P – lupz May 01 '12 at 03:38
  • 1
    Honestly, it's not hard to switch to `rdtsc`. – Mahmoud Al-Qudsi May 01 '12 at 03:50
  • My Machine does somewhat around 80 on the first example (Haven't figured out how to pass the mentioned parameter to g++ through eclipse, yet). I'd have never expected that inline assembly is only this few steps away. – lupz May 01 '12 at 04:51
  • Brought it down to 55 (Actually eclipse has a gui for optimization level...) – lupz May 01 '12 at 05:23
  • 1
    Find a number that works, then just subtract that from your reading before dividing by the frequency to get the most accurate value. But in reality, it doesn't matter: 55 is 0.000000022916 seconds if you're on a modest 2.4GHz processor. In other words: nothing. This is a ridiculously high-precision counter. – Mahmoud Al-Qudsi May 01 '12 at 05:48
  • I added my experimental C++ code on `rdtsc` to [codereview](http://codereview.stackexchange.com/q/11366/13029) for revision and sharing. – lupz May 01 '12 at 07:13
  • `clock_gettime` is not limited to this resolution. It will be using the TSC register as well and should provide high precision times. – edA-qa mort-ora-y May 01 '12 at 07:17
  • @edA-qamort-ora-y I never said it was. I said `/proc/status` jiffies are. – Mahmoud Al-Qudsi May 01 '12 at 07:19
  • Finally I'll keep parsing `/proc/status` because the distinction between total jiffies, Idle jiffies and IO-wait jiffies is very valuable to my database experiments. It's even possible to count jiffies of a specific process. – lupz May 01 '12 at 07:32