public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
From: James Dabbs <JDabbs@TGA.com>
To: Grant Edwards <grante@visi.com>,
	"Pamulapati, Indrasena (CTS)" <pindrase@chn.cognizant.com>
Cc: ecos-discuss@sources.redhat.com
Subject: RE: [ECOS] Suitability of eCos
Date: Tue, 16 Jan 2001 07:52:00 -0000	[thread overview]
Message-ID: <F12384A3C489D411944100B0D07C673A065C1F@NS1-2> (raw)

Generally speaking, when your real-time threads are using up their entire
timeslice, you are probably out of CPU bandwidth.  Timeslices are usually
not used for real-time response, but for lower-priority supervisory threads
with less demanding requirements.  It sounds like you need to use a delta
timer queue driven from a HW high-precision timer.  While the OS is
"ticking" away timeslices once every 100mS, this timer is scheduling
activity on a microsecond basis.

-----Original Message-----
From: Grant Edwards [ mailto:grante@visi.com ]
Sent: Tuesday, January 16, 2001 10:31 AM
To: Pamulapati, Indrasena (CTS)
Cc: ecos-discuss@sources.redhat.com
Subject: Re: [ECOS] Suitability of eCos


On Tue, Jan 16, 2001 at 03:19:17PM +0530, Pamulapati, Indrasena (CTS) wrote:

> What u say is right. As we decrease the tick duration the
> efficiency of the OS comes down because of the overhead
> involved in processing the tick.
>
> But my application requires tick duration as low as a
> 100microseconds. I need to address such low time resolutions.

That may not mean that you have to have an OS tick that small.
If your critical tasks are driven by interrupts, then the
length of the OS tick isn't particulary important -- it's
driven more by the resolution needed on things like the
timeouts you want when waiting for an event that doesn't
happen.

> I feel there should be some parameters of rtos's that have to
> be considered with reference to the application we are building
> before deciding the OS.

Of course there are.  But you are the only one who knows what
the most important factors are.  If you tell us what those
factors are, perhaps we can tell you how well eCos suits your
application.

-- 
Grant Edwards
grante@visi.com

             reply	other threads:[~2001-01-16  7:52 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-01-16  7:52 James Dabbs [this message]
  -- strict thread matches above, loose matches on Subject: below --
2001-01-16 11:08 Pamulapati, Indrasena (CTS)
2001-01-16  4:52 ` Jesper Skov
2001-01-16 11:26 ` Grant Edwards
2001-01-16  4:07 Stenberg Björn
2001-01-16  1:52 Pamulapati, Indrasena (CTS)
2001-01-16  2:44 ` Jesper Skov
2001-01-16  7:27 ` Grant Edwards
2001-01-16  1:27 Ramana
2001-01-16  1:10 Pamulapati, Indrasena (CTS)

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=F12384A3C489D411944100B0D07C673A065C1F@NS1-2 \
    --to=jdabbs@tga.com \
    --cc=ecos-discuss@sources.redhat.com \
    --cc=grante@visi.com \
    --cc=pindrase@chn.cognizant.com \
    /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 read-only IMAP folder(s) and NNTP newsgroup(s).