This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Maximum RTC Tick Rate


At the moment, I'm running on a test platform- a 450 MHz Pentium II Compaq
Deskpro- probably a bit more powerful than the average embedded CPU.  The
reason for the high clock rate is (probably) twofold- the need to implement
sub-ms timeouts in my app, and a lack of experience with eCos.  Currently, I
use the RTC to drive all the timers in my app, using
cyg_clock_to_counter( ), with an associated alarm and a flag for signaling
timer expiration.  If anyone has any pointers regarding a more efficient way
to do timing, I'm all ears!!!

Cheers,
Fred Woolsey

----- Original Message -----
From: "Jonathan Larmour" <jifl@eCosCentric.com>
To: "Fred Woolsey" <fwsbcon@fwsbcon.com>
Cc: "Gary D. Thomas" <gary.thomas@mind.be>; "eCos Discussion"
<ecos-discuss@sources.redhat.com>
Sent: Wednesday, February 12, 2003 7:08 PM
Subject: Re: [ECOS] Maximum RTC Tick Rate


> Gary D. Thomas wrote:
> > On Wed, 2003-02-12 at 16:55, Fred Woolsey wrote:
> >
> >>Does anyone have info on the maximum real-time clock tick frequency that
> >>eCos can handle on an i386 platform?  I've built a test app with a tick
> >>interval of 100 us, which appears to work OK.
> >
> >
> > One way to determine this would be to run the standard
> > test 'tm_basic' with CLOCK_LATENCY turned on.  This will
> > tell you not only the time to service the clock interrupt,
> > but also the DSR and ISR latencies associated with it.
> >
> > My guess is (depending on your actual hardware) that at
> > a clock rate of 100us/tick, you're probably spending a
> > fairly considerable percentage of time just processing
> > those interrupts (e.g. if the "round trip" time for the
> > clock tick as measured by 'tm_basic' is 10us, then you
> > would be using 10% of the CPU just to handle the clock
> > at that rate).
> >
> > The maximum clock rate would thus be related to how fast
> > your hardware is and how much of the CPU you are willing
> > to give up just to process the clock.
>
> Not just that. It's possible that too fast and something somewhere just
> "doesn't work". e.g. the timer just can't be driven that fast, e.g.
> <http://sources.redhat.com/ml/ecos-discuss/2003-01/msg00300.html>
>
> Jifl
> --
> eCosCentric    http://www.eCosCentric.com/    The eCos and RedBoot experts
> --[ "You can complain because roses have thorns, or you ]--
> --[  can rejoice because thorns have roses." -Lincoln   ]-- Opinions==mine
>
>
> --
> Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
> and search the list archive: http://sources.redhat.com/ml/ecos-discuss
>
>
>
>



-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]