RE: [ECOS] Suitability of eCos

RE: [ECOS] Suitability of eCos

[Ramana]

Hi,

We are using ecos for some time now. It works quite well.

a. in general the OS tick should be about 10 ms or so and should nto be
very fast. We did have a requirement to increase this to 1 ms. However I
think this si about the maximum it can go.We are using 40 Mhz Power pc.
I dotn know why any one need a very fast OS tick. The OS tick is
basically for resolution of time and scheduling only.

b. For us the decision for ecos was quite simple. We needed open source
platform that we can change. And the cost was also a factor.
rgds
ramana


-----Original Message-----
From: Pamulapati, Indrasena (CTS) [ mailto:pindrase@chn.cognizant.com ]
Sent: Tuesday, January 16, 2001 2:40 PM
To: ecos-discuss@sources.redhat.com
Subject: [ECOS] Suitability of eCos


Hello,

I am building an application that has to handle very high data rates in
the
range of a couple of tens of Million bits/sec and handle data frames of
durations as low as a millisecond.
This will require me to have OS clock as high as 10000 ticks/sec. The
whole
thing is going to run in an embedded system with a real time operating
system.
The problem I am facing is,

1. How do I decide which real time operating system I have to choose. 

2. I want to know the kind of applications for which eCos is most
suitable
for.
    As most of u are building appications for various real time systems
there would have been some features of eCos that made it
particularly suitable for ur applications. Can u guys explain what
prompted
u to choose eCos as the rtos for ur applications.

Can u direct me to some resourses on the net that will help me in
deciding
the rtos that will be most suitable for applications of my kind.

bye,
Indrasena

	


This e-mail and any files transmitted with it are for the sole use of
the intended recipient(s) and may contain confidential and privileged
information.
If you are not the intended recipient, please contact the sender by
reply e-mail and destroy all copies of the original message. 
Any unauthorised review, use, disclosure, dissemination, forwarding,
printing or copying of this email or any action taken in reliance on
this e-mail is strictly 
prohibited and may be unlawful.

		Visit us at http://www.cognizant.com

Re: [ECOS] Suitability of eCos

[Grant Edwards]

On Tue, Jan 16, 2001 at 05:34:01PM +0530, Pamulapati, Indrasena (CTS) wrote:

> But does'nt the tick duration also determine the smallest addressable time
> unit.

Maybe not.

If you've got an extra hardware counter/timer, you can generally
configure it to cause an interrupt at a particular point in the
future.  The resolution of that "delay" period is determined by
the counter hardware and is independant of the rate at which
system-tick/scheduler interrupt occurs.

The most convenient situation would be to have a seperate
timer/counter for each possible parallel usage, but it's also
possible to simulate multiple counters by keeping a list of
pending delays and at each interrupt, set up the counter for
the interval until the next pending delay is to expire.

This technique will provide an interrupt at the end of each
delay period with extremely good accuracy without generating
excessive overhead.

You can start data transfer directly in the counter/timer ISR
or you can wake up a task and have it initiate the transfer.
Tasks waiting on events from ISRswill wake up whenever they
need to (assuming they are the highest priority runnable task)
independant of when the system-tick/scheduler interrupts happen.

Writing a "delay" device driver with a simple API which
consists of a single entry-point which blocks for a specified
period of time would be a fairly straight-forward task if you
wanted to try to isolate the various device drivers from each
other by passing control through user-tasks..

-- 
Grant Edwards
grante@visi.com

RE: [ECOS] Suitability of eCos

[Pamulapati, Indrasena (CTS)]

Hi Jesper,

Yes, the tick duaration controls the kernel scheduler and I dont need
scheduling at that rate.
But does'nt the tick duration also determine the smallest addressable time
unit.
What i mean is:

Let us consider the duration of a tick to be a reasonable value of
10millisec.
Now, if I want to send some data at, say 20ms from the start of a reference
point,
I will give a delay of 2ticks from the reference point and as u mentioned
send an interrupt to the driver after 2ticks.

Now, what if I want to send the data after 1 ms from the reference point. I
will not be able to specify the number of ticks I have to wait if tick
duration is 10ms. So what I thought was, I can decrease the tick duration to
less that 1ms, say 0.5ms and give a delay of 2ticks and then send the
interrupt. But this I guess will adversly affect the performance of the
system.

Jesper, actually I am quite a newbie wrt drivers and rtos's.
	Can you elaborate on
	 "Drivers doing IO should be driven separately, relying on device
interrupts, not scheduler interrupts, for state transitions." based on the
problem I mentioned above. I guess this may solve my problem.
 
Regards,
Indrasena

  

> -----Original Message-----
> From:	Jesper Skov [SMTP:jskov@redhat.com]
> Sent:	Tuesday, January 16, 2001 4:14 PM
> To:	Pamulapati, Indrasena (CTS)
> Cc:	ecos-discuss@sources.redhat.com
> Subject:	Re: [ECOS] Suitability of eCos
> 
> >>>>> "Pamulapati," == Pamulapati, Indrasena (CTS)
> <pindrase@chn.cognizant.com> writes:
> 
> Pamulapati,> the overhead involved in processing the tick.  But my
> Pamulapati,> application requires tick duration as low as a
> Pamulapati,> 100microseconds. I need to address such low time
> Pamulapati,> resolutions.
> 
> As Ramana pointed out, the tick duration controls little more than
> the kernel scheduler in eCos. Surely you don't need thread scheduling
> at that rate!?!
> 
> Drivers doing IO should be driven separately, relying on device
> interrupts, not scheduler interrupts, for state transitions.
> 
> But without further information about your application my comments
> above are just guesses and may not actually apply...
> 
> Jesper

This e-mail and any files transmitted with it are for the sole use of the intended recipient(s) and may contain confidential and privileged information.
If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. 
Any unauthorised review, use, disclosure, dissemination, forwarding, printing or copying of this email or any action taken in reliance on this e-mail is strictly 
prohibited and may be unlawful.

		Visit us at http://www.cognizant.com

RE: [ECOS] Suitability of eCos

[James Dabbs]

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

Re: [ECOS] Suitability of eCos

[Grant Edwards]

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

RE: [ECOS] Suitability of eCos

[Jesper Skov]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2111 bytes --]

>>>>> "Pamulapati," == Pamulapati, Indrasena (CTS) <pindrase@chn.cognizant.com> writes:

Pamulapati,> Hi Jesper, Yes, the tick duaration controls the kernel
Pamulapati,> scheduler and I dont need scheduling at that rate.  But
Pamulapati,> does'nt the tick duration also determine the smallest
Pamulapati,> addressable time unit.  What i mean is:

Pamulapati,> Let us consider the duration of a tick to be a reasonable
Pamulapati,> value of 10millisec.  Now, if I want to send some data
Pamulapati,> at, say 20ms from the start of a reference point, I will
Pamulapati,> give a delay of 2ticks from the reference point and as u
Pamulapati,> mentioned send an interrupt to the driver after 2ticks.

If you want to busywait, use the uS delay function instead.

But as Björn Stenberg pointed out, you probably want a high-speed
timer to driver things instead of relying on the kernel scheduler
timer.

Pamulapati,> Jesper, actually I am quite a newbie wrt drivers and
Pamulapati,> rtos's.  Can you elaborate on "Drivers doing IO should be
Pamulapati,> driven separately, relying on device interrupts, not
Pamulapati,> scheduler interrupts, for state transitions." based on
Pamulapati,> the problem I mentioned above. I guess this may solve my
Pamulapati,> problem.
 
If you want to do something from a reference point, in context of a
real-time OS, isn't that something pushing data out or reading data
from some device? Audio for instace?

Anyway, most hardware controllers that deal with large amounts of
data throughput have means to interrupt the CPU on completion of a
task. That is, instead of doing this:

 CPU:  send data1, wait 20ms, send data2, wait 20ms, send data3...

(which I think is what you suggest) you get:

 CPU:  idle.......|            | idle.... | 
 IRQ:               send data1              send data2

device interrupt: X                       X


Hope that makes sense. In words: when the CPU is interrupted, send the
next datum. When not sending data, the CPU idles.  Whether that
interrupt comes from the driver handling the data, or a high-speed
timer doesn't really matter.

Jesper

RE: [ECOS] Suitability of eCos

[Stenberg Björn]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 938 bytes --]

> 	But my application requires tick duration as low as a
> 100microseconds. I need to address such low time resolutions.

Don't confuse tick resolution with timer resolution. Many hardware platforms
for embedded use have timers with very high resolution. Many systems need
high-resolution timing. That does not mean you have to, or even should, run
your OS tick at those resolutions.

If you need a high-resolution timer, use one. It will send you an interrupt
precisely when you want it to and you can then act on it immediately.
Implement proper queueing/buffering/whatever there so your application can
handle the high data load in a controlled manner.

If you set your OS tick to a very high rate, your system will spend more
time in the kernel and have less time to do the actual work, and you may
ultimately find yourself with a performance problem.

-- 
Björn Stenberg
bjorn.stenberg@contactor.se
http://www.contactor.se/~bjst/

Re: [ECOS] Suitability of eCos

[Jesper Skov]

>>>>> "Pamulapati," == Pamulapati, Indrasena (CTS) <pindrase@chn.cognizant.com> writes:

Pamulapati,> the overhead involved in processing the tick.  But my
Pamulapati,> application requires tick duration as low as a
Pamulapati,> 100microseconds. I need to address such low time
Pamulapati,> resolutions.

As Ramana pointed out, the tick duration controls little more than
the kernel scheduler in eCos. Surely you don't need thread scheduling
at that rate!?!

Drivers doing IO should be driven separately, relying on device
interrupts, not scheduler interrupts, for state transitions.

But without further information about your application my comments
above are just guesses and may not actually apply...

Jesper

RE: [ECOS] Suitability of eCos

[Pamulapati, Indrasena (CTS)]

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

	And yes, the choice of eCos for most of us will be because it is
opensource.
	But dont we need to consider the suitability of a particular OS for
the application we are building for maximum efficiency?
	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. 

> -----Original Message-----
> From: Ramana [ mailto:ramanabv@danlawinc.com ] 
> Sent: Tuesday, January 16, 2001 2:52 PM
> To: ecos-discuss@sources.redhat.com
> Subject: RE: [ECOS] Suitability of eCos
> 
> 
> Hi,
> 
> We are using ecos for some time now. It works quite well.
> 
> a. in general the OS tick should be about 10 ms or so and should nto be
> very fast. We did have a requirement to increase this to 1 ms. However I
> think this si about the maximum it can go.We are using 40 Mhz Power pc.
> I dotn know why any one need a very fast OS tick. The OS tick is
> basically for resolution of time and scheduling only.
> 
> b. For us the decision for ecos was quite simple. We needed open source
> platform that we can change. And the cost was also a factor.
> rgds
> ramana
> 
> 
> -----Original Message-----
> From: Pamulapati, Indrasena (CTS) [ mailto:pindrase@chn.cognizant.com ]
> Sent: Tuesday, January 16, 2001 2:40 PM
> To: ecos-discuss@sources.redhat.com
> Subject: [ECOS] Suitability of eCos
> 
> 
> Hello,
> 
> I am building an application that has to handle very high data rates in
> the
> range of a couple of tens of Million bits/sec and handle data frames of
> durations as low as a millisecond.
> This will require me to have OS clock as high as 10000 ticks/sec. The
> whole
> thing is going to run in an embedded system with a real time operating
> system.
> The problem I am facing is,
> 
> 1. How do I decide which real time operating system I have to choose. 
> 
> 2. I want to know the kind of applications for which eCos is most
> suitable
> for.
>     As most of u are building appications for various real time systems
> there would have been some features of eCos that made it
> particularly suitable for ur applications. Can u guys explain what
> prompted
> u to choose eCos as the rtos for ur applications.
> 
> Can u direct me to some resourses on the net that will help me in
> deciding
> the rtos that will be most suitable for applications of my kind.
> 
> bye,
> Indrasena
> 
> 	
> 
> 
> This e-mail and any files transmitted with it are for the sole use of
> the intended recipient(s) and may contain confidential and privileged
> information.
> If you are not the intended recipient, please contact the sender by
> reply e-mail and destroy all copies of the original message. 
> Any unauthorised review, use, disclosure, dissemination, forwarding,
> printing or copying of this email or any action taken in reliance on
> this e-mail is strictly 
> prohibited and may be unlawful.
> 
> 		Visit us at http://www.cognizant.com

This e-mail and any files transmitted with it are for the sole use of the intended recipient(s) and may contain confidential and privileged information.
If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. 
Any unauthorised review, use, disclosure, dissemination, forwarding, printing or copying of this email or any action taken in reliance on this e-mail is strictly 
prohibited and may be unlawful.

		Visit us at http://www.cognizant.com

[ECOS] Suitability of eCos

[Pamulapati, Indrasena (CTS)]

Hello,

I am building an application that has to handle very high data rates in the
range of a couple of tens of Million bits/sec and handle data frames of
durations as low as a millisecond.
This will require me to have OS clock as high as 10000 ticks/sec. The whole
thing is going to run in an embedded system with a real time operating
system.
The problem I am facing is,

1. How do I decide which real time operating system I have to choose. 

2. I want to know the kind of applications for which eCos is most suitable
for.
    As most of u are building appications for various real time systems
there would have been some features of eCos that made it
particularly suitable for ur applications. Can u guys explain what prompted
u to choose eCos as the rtos for ur applications.

Can u direct me to some resourses on the net that will help me in deciding
the rtos that will be most suitable for applications of my kind.

bye,
Indrasena

	


This e-mail and any files transmitted with it are for the sole use of the intended recipient(s) and may contain confidential and privileged information.
If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. 
Any unauthorised review, use, disclosure, dissemination, forwarding, printing or copying of this email or any action taken in reliance on this e-mail is strictly 
prohibited and may be unlawful.

		Visit us at http://www.cognizant.com