Bug 428196 - CLOCKS_PER_SECOND clearly is not
CLOCKS_PER_SECOND clearly is not
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: glibc (Show other bugs)
8
i386 Linux
low Severity low
: ---
: ---
Assigned To: Jakub Jelinek
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-01-09 16:38 EST by Scott Mcdermott
Modified: 2008-01-09 20:36 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-01-09 16:55:16 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
program that uses CPU for a specified amount of time and prints tms_utimes divided by CLOCKS_PER_SECOND (536 bytes, text/plain)
2008-01-09 16:38 EST, Scott Mcdermott
no flags Details
add documentation to times() in glibc texinfo to use sysconf() to get the interval of units in struct tms, rather than the implied CLOCKS_PER_SECOND (918 bytes, patch)
2008-01-09 20:26 EST, Scott Mcdermott
no flags Details | Diff

  None (edit)
Description Scott Mcdermott 2008-01-09 16:38:33 EST
CLOCKS_PER_SECOND is set to 1 million but this division is not correct.  I am using the tms_utime or tms_stime field of struct tms to compute time spent on some particular activity in my program.  These are clock_t variables and as such, division of some interval of clock_t by CLOCKS_PER_SECOND should result in the number of seconds spent in the interval.  However, this is clearly not the case.  Please note the output of the attached program.  The raw values of tms_utime are in hundredths of a second, not millionths as CLOCKS_PER_SECOND would indicate.

Here is a run for 10 seconds:

     $ time ./ttest 10
    raw delta: 985, secs: 0
    real    0m10.005s
    user    0m9.859s
    sys     0m0.013s

the raw clock_t of user time spent was only 985, which clearly corresponds to hundredths of a second, not millionths as CLOCKS_PER_SECOND would indicate.  According to the glibc info page, "All of the times are given in numbers of clock ticks" as evidenced by the clock_t type, but the description in glibc info page node "Processor And CPU Time" describes this type as being millionths of a second, wrapping around every 7 minutes on 32 bit systems.

I'm not sure if CLOCKS_PER_SECOND is wrong, if the tms_utime field is not being updated properly, or if the documentation is not correct, but one of these must be the case as I understand it.
Comment 1 Scott Mcdermott 2008-01-09 16:38:33 EST
Created attachment 291206 [details]
program that uses CPU for a specified amount of time and prints tms_utimes divided by CLOCKS_PER_SECOND
Comment 2 Jakub Jelinek 2008-01-09 16:55:16 EST
You haven't bothered to read the man page, right?
http://www.opengroup.org/onlinepubs/009695399/functions/times.html
...
All times are measured in terms of the number of clock ticks used.
...
Applications should use sysconf(_SC_CLK_TCK) to determine the number of clock
ticks per second as it may vary from system to system.

man 2 times and man 3p times contain similar wording.
Comment 3 Scott Mcdermott 2008-01-09 20:26:20 EST
Created attachment 291219 [details]
add documentation to times() in glibc texinfo to use sysconf() to get the interval of units in struct tms, rather than the implied CLOCKS_PER_SECOND
Comment 4 Scott Mcdermott 2008-01-09 20:36:08 EST
You're right that I missed that, having looked only at the texinfo
documentation.  However, I was under the impression that the texinfo
documentation was authoritative for glibc, and the information shown there is
misleading, in my opinion, or at least inadequate.

I attached a patch to the texinfo documentation that will bring it into
consistency with the wording found in the referenced manual pages.  If you like
I can try to get it upstream instead of bothering fedora developers with having
to put it in glibc-fedora.patch, but I do think it's important to include it.

Note You need to log in before you can comment on or make changes to this bug.