Hi again,
Thanks for your really quick replies and your contributions! I have
found some interesting info:
Luis Claudio R. Goncalves escribió:
On Tue, Dec 01, 2009 at 07:14:45AM -0500, Hector Perez Tijero wrote:
Hi,
My question might be a little basic for this list... Maybe someone could
point me out to another forum :)
I'm trying to get some measures using the execution time clock in my
system and I found some slight differences in the use of the
CLOCK_THREAD_CPUTIME_ID and CLOCK_MONOTONIC clocks. The measures are
between the same points of code. My concern is that, sometimes, the
measure obtained with CLOCK_MONOTONIC is lower than using
CLOCK_THREAD_CPUTIME_ID. Find below a dummy example to test this strange
behavior.
It doesn't happen very often but the error could be around hundreds of
microseconds.
So my question is: are both POSIX clocks based on different physical
clocks? I always though they use the TSC...
Check the dmesg logs for hints on TSC. There are some TSCs that are not
used as clocksources because they are out-of-sync between CPUs, because
they halt on idle, because they halt on inner C-states and so on...
My dmesg output:
[ 8.333748] checking TSC synchronization [CPU#0 -> CPU#1]:
[ 8.353732] Measured 3359526540 cycles TSC warp between CPUs,
turning off TSC clock.
[ 8.353737] Marking TSC unstable due to: check_tsc_sync_source
failed.
So my system is not using the TSC...
My previous guess was that such behavior could be caused by the CPU
frequency scaling but the same happened when I disabled it.
How many CPUs?
A DualCore.
>From http://www.tin.org/bin/man.cgi?section=3&topic=clock_gettime :
NOTE for SMP systems
The CLOCK_PROCESS_CPUTIME_ID and CLOCK_THREAD_CPUTIME_ID clocks are
realized on many platforms using timers from the CPUs (TSC on i386,
AR.ITC on Itanium). These registers may differ between CPUs and as a
consequence these clocks may return bogus results if a process is
migrated to another CPU.
Yeah, I have check the available clocks in
/sys/devices/system/clocksource/clocksource0/available_clocksource
>>hpet acpi_pm jiffies tsc
and the clock used according to cat
/sys/devices/system/clocksource/clocksource0/current_clocksource
>>hpet
I have switched to acpi_pm but the same issue exists. I have also
disabled one CPU in the BIOS to use the TSC... I though it could be good
try but... useless
By definition, CLOCK_MONOTONIC seems to be what you want.
No, I actually need the CLOCK_THREAD_CPUTIME_ID. Basically I have to get
some execution times measures to perform the schedulability analysis.
But I have found this strange behavior and I just wonder why.
Another interesting detail is that you have to check what is the value of
/proc/sys/kernel/vsyscall64 for it constrols the behavior and resolution of
clock reads (enabling or disabling VDSO clock enhancements). Try setting it
to zero and repeating your tests.
That functionality is only for 64bits, isn't it? My computer is still 32
bits... :)
Please let me know any new suggestion...
Regards,
Hector
--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
