linux-rt-users.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Luis Claudio R. Goncalves" <lclaudio@uudg.org>
To: Hector Perez Tijero <perezh@unican.es>
Cc: linux-rt-users@vger.kernel.org
Subject: Re: Posix Execution time clock
Date: Tue, 1 Dec 2009 10:32:28 -0200	[thread overview]
Message-ID: <20091201123228.GM3864@uudg.org> (raw)
In-Reply-To: <4B1508B5.7030202@unican.es>

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 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?

>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.

By definition, CLOCK_MONOTONIC seems to be what you want.

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.

Along with that, the latest version for 2.6.24, IIRC, was 2.6.24.7-rt27.
So, it sounds like you are using older versions of old software.

Regards,
Luis
-- 
[ Luis Claudio R. Goncalves                    Bass - Gospel - RT ]
[ Fingerprint: 4FDD B8C4 3C59 34BD 8BE9  2696 7203 D980 A448 C8F8 ]


  parent reply	other threads:[~2009-12-01 12:32 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-12-01 12:14 Posix Execution time clock Hector Perez Tijero
2009-12-01  9:53 ` Uwe Kleine-König
2009-12-01 12:32 ` Luis Claudio R. Goncalves [this message]
2009-12-02  9:01   ` Hector Perez Tijero
2009-12-02 19:08   ` Uwe Kleine-König
2009-12-05  2:23     ` Hector Perez Tijero

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20091201123228.GM3864@uudg.org \
    --to=lclaudio@uudg.org \
    --cc=linux-rt-users@vger.kernel.org \
    --cc=perezh@unican.es \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).