Okay -- as a first step to resolving this, I've adjusted the text in
time.7, including adding a mention of HRTs.  The text that I plan to
put in man-pages-3.01 is shown below.  Does it look okay to you
Stephane?

   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 deter-
       mined by the value of the kernel constant HZ.

       The value of HZ varies across kernel versions  and  hard-
       ware  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, respectively, 0.01, 0.004,
       or 0.001 seconds.  Since kernel 2.6.20,  a  further  fre-
       quency  is  available:  300, a number that divides evenly
       for the common video frame rates (PAL, 25  HZ;  NTSC,  30
       HZ).

   High-Resolution Timers
       Before Linux 2.6.16, the accuracy of timer and sleep sys-
       tem calls (see below) was also limited by the size of the
       jiffy.

       Since Linux 2.6.16, Linux supports high-resolution timers
       (HRTs), optionally configurable since kernel  2.6.21  via
       CONFIG_HIGH_RES_TIMERS.   On a system that supports HRTs,
       the accuracy of sleep and timer system calls is no longer
       constrained  by the jiffy, but instead can be as accurate
       as the hardware allows (microsecond accuracy  is  typical
       of modern hardware).
  ...

   Sleeping and Setting Timers
       Various system calls and functions  allow  a  program  to
       sleep (suspend execution) for a specified period of time;
       see nanosleep(2), clock_nanosleep(2), and sleep(3).

       Various system calls allow a process to set a timer  that
       expires  at  some  point in the future, and optionally at
       repeated   intervals;   see    alarm(2),    getitimer(2),
       timerfd_create(2), and timer_create(3).



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Reply via email to