collecting timer resolution information...
I'd like people to run the attached C program and send the output to me. What this does is run the gettimeofday() and getrusage() functions until the time values change. The intent is to determine the quality of the available timing information. For example, on my Linux-Mandrake 7.2 installation with a stock 2.2.17 kernel, I get this: timeofday: 1 (1 calls), rusage: 10000 (2465 calls) Thanks! -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> PythonLabs at Digital Creations
Fred L. Drake, Jr. writes:
I'd like people to run the attached C program and send the output to
OK, I've attached it this time. Sorry!
-Fred
--
Fred L. Drake, Jr. <fdrake at acm.org>
PythonLabs at Digital Creations
#include
Here are the results from a few machines around here: s454% uname -a SunOS s454 5.7 Generic_106541-10 sun4m sparc SUNW,SPARCstation-4 s454% observation timeofday: 2 (1 calls), rusage: 10000 (22 calls) oma% uname -a SunOS oma 5.7 Generic sun4u sparc SUNW,Ultra-4 oma% observation timeofday: 1 (2 calls), rusage: 10000 (115 calls) pc250% uname -a SunOS pc250 5.8 Generic_108529-03 i86pc i386 i86pc pc250% observation timeofday: 1 (1 calls), rusage: 10000 (232 calls) Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg@cosc.canterbury.ac.nz +--------------------------------------+
Neil Schemenauer writes:
My hacked version of Linux 2.4 on an AMD-800 box:
timeofday: 1 (2 calls), rusage: 976 (1792 calls)
I don't quite understand the output. What does the 976 mean?
The "1" and the "976" are the appearant resolution of the time values reported by those two calls, in microseconds. It looks like the HZ define in that header file you pointed out could be bumped a little higher. ;-) -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> PythonLabs at Digital Creations
Fred L. Drake, Jr. wrote:
The "1" and the "976" are the appearant resolution of the time values reported by those two calls, in microseconds. It looks like the HZ define in that header file you pointed out could be bumped a little higher. ;-)
I've got it at 1024. >>> 976. / 10000 * 1024 99.942400000000006 I think yours is at the 100 default. Neil
Neil Schemenauer writes:
I've got it at 1024.
>>> 976. / 10000 * 1024 99.942400000000006
I think yours is at the 100 default.
That's correct. Yours could be bumped a bit (factor of 10? I'm not really sure where it would cause problems in practice, though I think I understand the general explanations I've seen), and mine could be bumped a good bit. But I intend to stick with a stock kernel since I expect most users will be using a stock kernel, and I don't have a pile of extra machines to play with. ;-( -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> PythonLabs at Digital Creations
participants (3)
-
Fred L. Drake, Jr.
-
Greg Ewing
-
Neil Schemenauer