Re: Posix Execution time clock

[Hector Perez Tijero <perezh@unican.es>]

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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html