Take the 2-minute tour ×

I'd like to know the HZ of the system, i.e. how many mili seconds is one jiffy from Python code.

share|improve this question
what's a jiffy? –  knitti Nov 15 '10 at 21:52
the timer interrupt interval, which determines the accuracy of all thread sleep operations, etc –  Ben Voigt Nov 15 '10 at 21:53
@knitti, "I'll get that for you in one jiffy". I think its equal to "real quick". –  jlafay Nov 15 '10 at 21:53
Python is a high-level language which makes any number you'll get pretty much meaningless. So... any specific thing you need it for? –  Wolph Nov 15 '10 at 22:40
@MarkR: hung task detection by reading the jiffies per millisecond from /proc with Python? I recommend you read up on how jiffies are defined on modern computers. I believe that your definition is either incorrect or simply outdated. –  Wolph Nov 17 '10 at 19:04

2 Answers 2

There is USER_HZ

>>> import os
>>> os.sysconf_names['SC_CLK_TCK']
>>> os.sysconf(2)

which is what the kernel uses to report time in /proc.

From the time(7) manual page:

The Software Clock, HZ, and Jiffies

The accuracy of various system calls that set timeouts, (e.g., select(2), sigtimedwait(2)) and measure CPU time (e.g., getrusage(2)) is limited by the resolution of the software clock, a clock maintained by the kernel which measures time in jiffies. The size of a jiffy is determined by the value of the kernel constant HZ.

The value of HZ varies across kernel versions and hardware platforms. On i386 the situation is as follows: on kernels up to and including 2.4.x, HZ was 100, giving a jiffy value of 0.01 seconds; starting with 2.6.0, HZ was raised to 1000, giving a jiffy of 0.001 seconds. Since kernel 2.6.13, the HZ value is a kernel configuration parameter and can be 100, 250 (the default) or 1000, yielding a jiffies value of, respec‐ tively, 0.01, 0.004, or 0.001 seconds. Since kernel 2.6.20, a further frequency is available: 300, a number that divides evenly for the com‐ mon video frame rates (PAL, 25 HZ; NTSC, 30 HZ).

The times(2) system call is a special case. It reports times with a granularity defined by the kernel constant USER_HZ. Userspace applica‐ tions can determine the value of this constant using sysconf(_SC_CLK_TCK).

If you absolutely must know SYSTEM_HZ:

>>> from ctypes import *
>>> rt = CDLL('librt.so')
>>> class timespec(Structure):
...     _fields_ = [("tv_sec", c_long), ("tv_nsec", c_long)]
>>> res = timespec()
>>> rt.clock_getres(CLOCK_REALTIME, byref(res))
>>> res.tv_sec, res.tv_nsec
(0, 4000250)
>>> SYSTEM_HZ = round(1/(res.tv_sec + (res.tv_nsec/10.0**9)))

Gives 250 on my laptop (which sounds about right) and 1000000000 in a VM…

share|improve this answer
I'm trying to calculate some stuff based on jiffies which should really be in ms. So, if know HZ equivalent, then jiffies * 1000/os.sysconf(2) = ms. At least I think so. –  Murgh Nov 16 '10 at 13:15
where do your jiffies come from? also, your equation is weird. –  hop Nov 16 '10 at 13:54
jiffies come from stime, utime and other timing related proeprties found in /proc/stat and similar files. Equation comes from unixtop.org. elapsed = timediff.tv_sec * HZ + (timediff.tv_usec * HZ) / 1000000; Since HZ is not available in Python, I was looking for the alternative. –  Murgh Nov 16 '10 at 15:40
@Murgh: those are reported in USER_HZ, so what are you still missing? –  hop Nov 17 '10 at 11:50
@hop: Well yes, they are in jiffies, but to get the elapsed time in jiffies from timeA to timeB i need to multiply the ms with HZ. So I need to know the HZ in order to calculate it. –  Murgh Nov 17 '10 at 14:36

sysconf(SC_CLK_TCK) does not give the frequency of the timer interrupts in Linux. It gives the frequency of jiffies which is visible to userspace in things like the counters in various directories in /proc

The actual frequency is hidden from userspace, deliberately. Indeed, some systems use dynamic ticks or "tickless" systems, so there aren't really any at all.

All the userspace interfaces use the value from SC_CLK_TCK, which as far as I can see is always 100 under Linux.

share|improve this answer
no, i think the value depends on the architecture –  hop Nov 16 '10 at 10:00
Yes, it is architecture dependent and is hard-coded at 100 in most (but perhaps not all) architectures in recent kernels. –  MarkR Nov 16 '10 at 13:15

Your Answer


