Thread: clock vs gettimeofday

Originally Posted by matsp

The 4ms lag is probably what I described, a system-wide scheduler lock for some "big job" in the kernel, where the kernel needs to ensure that the entire task is complete before it releases the lock. There are probably other ways to solve that sort of problem when writing the kernel, but the kernel was NEVER written to be good at real-time performance.

My suggestion was to sleep a longer period to reduce the risk of colliding with other tasks - because if you "interrupt" the system 2000 times a second (0.5 ms), you will use up a fair amount of CPU time just doing that.

--
Mats

I have two threads, both nanosleeping() for 0.5 ms. They both do partial drawing. First every 20 ms, second every 40 ms (i shifted startup of first by 5ms so they colide as little as possible). It's single core CPU celeron 1.6 Mhz. When under full load (most intesive scrolling), these two threads use 10%. Under normal drawing they use 3%. When i use bigger step, if they miss by more than 3ms, it's practicly visible. (It's all because of that slow library, i have these 'issues').

EDIT: even 2ms lag if happens few times is more than visible!

When you are reading from disk, there will be "no" time from "clock()", because the CPU is able to work for other processes in the system [if there is none, then it becomes the "idle" process that runs, and "clock()" for the idle process gets counted up].

If you read "main memory" then the CPU is busy in your process, so that time is counted in clock().

If multiple threads are running at the same time, clock() will increase for each thread.

To measure application performance, you probably want to have BOTH "walltime" (gettimeofday() time) and CPU-time (clock() time), and use the combination of them to determine the overall application performance.

--
Mats