LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: "Remy Bohmer" <linux@bohmer.net>
To: "David Brownell" <david-b@pacbell.net>,
	"Bosko Radivojevic" <bosko.radivojevic@gmail.com>
Cc: lkml <linux-kernel@vger.kernel.org>,
	linux-rt-users@vger.kernel.org, tglx@linutronix.de
Subject: Re: High resolution timers on AT91SAM926x
Date: Tue, 4 Mar 2008 21:22:24 +0100	[thread overview]
Message-ID: <3efb10970803041222j61fd8d28k5cef0994b9bd6f12@mail.gmail.com> (raw)
In-Reply-To: <200803031729.19264.david-b@pacbell.net>

Hello Bosko/Dave,

> On Monday 03 March 2008, Bosko Radivojevic wrote:
>
> > I had CONFIG_ATMEL_TCLIB enabled, but not TCB_CLKSRC and
>  > TCB_CLKSRC_BLOCK=0. With all those options, I finally have HRT
>  > functionality. But, strange thing is that jitter of my little example
>  > (get time, sleep 1ms, get time, show the difference) is around 250us.
>  > Maybe this is normal for this architecture?
> I have no idea why that would be.  Maybe you can find out.  :)

These are normal figures for this core, on preempt-rt.
You are talking about jitter on timers. While on preempt-rt the worst
case latency of scheduling a RT-thread is about 300us, 250us is thus
quite normal, and actually quite good... (the kernel-mainline average
latency is better, but worst-case is unbound)
(Note: The 300 us seem to be caused by something in the networking
layer, without network I noticed worst case latencies about 150us, but
NO guarantee here)

But, besides the worst-case schedule latency; the interrupt handler is
shared with the handler of the DBGU. There are patches available to
split the interrupt handler, this will make this behavior somewhat
better, but do not expect miracles here.

I stopped using HRT on these cores and preempt-RT for quite some time
now (several months), because the smaller timer granularity will allow
applications to make timers elapse on sub-millisec intervals, where
each interval generates a interrupt handling cycle of about 50 -
>100us, especially if different applications use periodic timers which
are out of sync.
This will become visible as extreme CPU-load figures on applications
with 1 ms timers.
13-15% CPU load on a application with just 1 single 1 ms timer is
quite normal...

FWIW: For getting the most accurate realtime response for periodic
timers, I used a TC block to generate a periodic interrupt, that only
needs to wake up a RT-thread. This way the OS-timer framework can be
used for non-RT stuff, and/or slow timers. This is much less heavy on
this core, and gives much better/deterministic RT results.
(This is not what I prefer to do, but these cores are just not that
fast as multi-gigahertz X86 PCs ;-)) )


Kind Regards,

Remy

>
>
>
>  > System is (as noted on rt.wik site) very slow with NO_HZ option enabled.
>
>
> It doesn't exactly say *why* or compare to other arm926ejs
>  chips ...
>
>  Could the 64-bit math (ktime stuff) be a factor there?  Your
>  board probably only runs at 95 (or-so) bogomips after all.
>
>  And is that just a NO_HZ issue, or generically an issue when
>  oneshot timer modes are in heavy use?
>
>  - Dave
>
>
>  --
>  To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>
> the body of a message to majordomo@vger.kernel.org
>  More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
> Please read the FAQ at  http://www.tux.org/lkml/
>

  reply	other threads:[~2008-03-04 20:22 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-03-01 22:57 David Brownell
2008-03-03 10:26 ` Bosko Radivojevic
2008-03-03 18:39   ` David Brownell
2008-03-03 21:42     ` Bosko Radivojevic
2008-03-04  1:29       ` David Brownell
2008-03-04 20:22         ` Remy Bohmer [this message]
2008-03-04 20:55           ` Wolfgang Grandegger
     [not found] <d6c8ef150803010952g666118dfu7679593b3c92c8be@mail.gmail.com>
2008-03-01 17:59 ` Bosko Radivojevic

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=3efb10970803041222j61fd8d28k5cef0994b9bd6f12@mail.gmail.com \
    --to=linux@bohmer.net \
    --cc=bosko.radivojevic@gmail.com \
    --cc=david-b@pacbell.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rt-users@vger.kernel.org \
    --cc=tglx@linutronix.de \
    --subject='Re: High resolution timers on AT91SAM926x' \
    /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

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