strange behavior with clock_gettime on fedora 13

[blah32]

Hey all,
I am using clock_gettime to do thread timing on a multithreaded program. When I just let the program run by, the deviation in thread times is very small. However, when I let the program run on an interference test with 8 youtube videos playing, the thread time is actually considerably less, even though the processors are bogged down. Does anyone have a way to explain this regarding linux?

Also, note I turned off TM2 and SpeedStep on my processor, so it's not that. Oh yeah, I have a core2quad.

[Rubberman]

Which clock were you using. There are a number to select from:

CLOCK_REALTIME
CLOCK_MONOTONIC
CLOCK_PROCESS_CPUTIME_ID
CLOCK_THREAD_CPUTIME_ID
CLOCK_REALTIME_HR
CLOCK_MONOTONIC_HR

[blah32]

Clock_thread_cputime_id

Also, its says 1ns resolution, but the quickest I can measure a difference between 2 calls to clock_gettime is 340ns. Thats way too high for what I need. Any idea how I can get to the utime for a thread much faster? (I also just want the user time)

which clock were you using. There are a number to select from:

Clock_realtime
clock_monotonic
clock_process_cputime_id
clock_thread_cputime_id
clock_realtime_hr
clock_monotonic_hr

[Rubberman]

Hey all,
I am using clock_gettime to do thread timing on a multithreaded program. When I just let the program run by, the deviation in thread times is very small. However, when I let the program run on an interference test with 8 youtube videos playing, the thread time is actually considerably less, even though the processors are bogged down. Does anyone have a way to explain this regarding linux?

As you saturate the CPU/core processing power with the videos playing, less CPU time is allocated to the threads in your application. Hence the thread CPU time used would be less in a given period, and your use of the CLOCK_THREAD_CPUTIME_ID timer type would show that. So, it is behaving as designed.

[blah32]

thanks

but what about the problem with the 2 measurements right in a row? Also, is there a way for me to get just the user time, not the kernal time too.

As you saturate the CPU/core processing power with the videos playing, less CPU time is allocated to the threads in your application. Hence the thread CPU time used would be less in a given period, and your use of the CLOCK_THREAD_CPUTIME_ID timer type would show that. So, it is behaving as designed.

[Rubberman]

Clock_thread_cputime_id

Also, its says 1ns resolution, but the quickest I can measure a difference between 2 calls to clock_gettime is 340ns. Thats way too high for what I need. Any idea how I can get to the utime for a thread much faster? (I also just want the user time)

Well, you can get the clock resolution with the clock_getres() function call. You should be able to set it with the clock_settime() function by modifying the timespec tv_nsec field that was returned in the clock_getres() call and passing that new timespec value to clock_settime() for the clock type you are setting. I haven't tried that, but it may well work to do what you want, to increase the CLOCK_THREAD_CPUTIME_ID clock resolution (smaller tv_nsec value == higher resolution).

[blah32]

my getres says 1 ns in the tv_nsec field it always has, yet I am saying the fastest I can make 2 calls in a row is about 340ns. I think this is because it is counting kernel time + user time. I want only user time.

Well, you can get the clock resolution with the clock_getres() function call. You should be able to set it with the clock_settime() function by modifying the timespec tv_nsec field that was returned in the clock_getres() call and passing that new timespec value to clock_settime() for the clock type you are setting. I haven't tried that, but it may well work to do what you want, to increase the CLOCK_THREAD_CPUTIME_ID clock resolution (smaller tv_nsec value == higher resolution).

[blah32]

I tried the settime idea, id didn't work.

Well, you can get the clock resolution with the clock_getres() function call. You should be able to set it with the clock_settime() function by modifying the timespec tv_nsec field that was returned in the clock_getres() call and passing that new timespec value to clock_settime() for the clock type you are setting. I haven't tried that, but it may well work to do what you want, to increase the CLOCK_THREAD_CPUTIME_ID clock resolution (smaller tv_nsec value == higher resolution).

[Rubberman]

Well, 1ns is 1 billionth of a second. On a 3Ghz processor, 1ns is only 3 cpu cycles - which is about 1 machine instruction... As for timing function calls, that it is taking some 340 ns for two function calls, still comes to only about 500 machine cycles per function call (170ns). Depending upon what the functions actually do, this is probably not a lot - its less than 0.2 microseconds per function call. 170 ns (500 cycles) @ 3 cycles / instruction is approximately 170 instructions per function call (average 1 instruction / nanosecond). Figure pushing/popping the stack, doing a call into the kernel, moving data around, etc. then this seems about right to me.

[blah32]

Is there anyway to just read the utime from the task_struct for the current thread?

Well, 1ns is 1 billionth of a second. On a 3Ghz processor, 1ns is only 3 cpu cycles - which is about 1 machine instruction... As for timing function calls, that it is taking some 340 ns for two function calls, still comes to only about 500 machine cycles per function call (170ns). Depending upon what the functions actually do, this is probably not a lot - its less than 0.2 microseconds per function call. 170 ns (500 cycles) @ 3 cycles / instruction is approximately 170 instructions per function call (average 1 instruction / nanosecond). Figure pushing/popping the stack, doing a call into the kernel, moving data around, etc. then this seems about right to me.