Re: [rtl] Soft Real Time

[yodaiken]

RTLinux on UP synergy boards is rock solid -- or at least it was not so
long ago.
SMP is waiting for time/money/interest.



On Sat, Jun 24, 2000 at 08:27:46AM -0700, al lykken wrote:
> I'm involved in a new project where we plan to use dual Power PC Synergy
> SBCs running
> Yellow Dog LINUX.  Since RT Linux doesn't seem to ready for prime time I
> have been trying
> to do deterministic scheduling with the existing system, with some
> success.  So far I:
> 
> 1.Changed my HZ from 100 to 1000
> 2.Set the running thread priority to 90 with sched_setscheduler
> 3.Locked the task in memory with mlockall
> 4.I used the interval timer, setitimer to do my scheduling
> 
> I am able to get tasks to down to ~1 ms.  And as lone as nothing else is
> 
> going on it is solid as a rock
> 
> The problem is that when another process is started, any access to disk,
> etc I blow my frame,
> where I get burps out to 10 - 30ms.
> 
> Is there anything else I might do to make my task more deterministic and
> is there any hope for RT Linux
> with Synergy (PPC).
> 
> Thanks..Al
> 
> 
> -- [rtl] ---
> To unsubscribe:
> echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
> echo "unsubscribe rtl " | mail [EMAIL PROTECTED]
> ---
> For more information on Real-Time Linux see:
> http://www.rtlinux.org/rtlinux/

-- 
-
Victor Yodaiken 
FSMLabs:  www.fsmlabs.com  www.rtlinux.com
FSMLabs is a servicemark and a service of 
VJY Associates L.L.C, New Mexico.

-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl " | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/

Re: [rtl] Soft Real Time

[yodaiken]

On Sun, Jun 25, 2000 at 12:04:36AM +0200, Herman Bruyninckx wrote:
> On Sat, 24 Jun 2000, Bernhard Kuhn wrote:
> 
> > Herman Bruyninckx wrote:
> > 
> > [ Asymetric Multiprocessing with Linux and another RTOS ]
> > 
> > > Sounds great, for things such as machine control, where you need a known
> > > and invarying number of small tasks that just have to run very fast.
> > 
> > That´s not the point! RT-Linux (and RTAI as well) are just fine for this
> > purpose - except the latencies caused by potential cache misses are too
> > big (usualy < 5 µs - IMHO, that´s quite ok for advanced machine control,
> > but who knows?). 
> We have a control problem in which we need a simple controller to run at
> preferably 30 000 Hz... So, keeping everything in cache is really needed...


Do you really need SMP _PowerPC_ ? If not we have something to beta test
on SMP x86.




-- 
-
Victor Yodaiken 
FSMLabs:  www.fsmlabs.com  www.rtlinux.com
FSMLabs is a servicemark and a service of 
VJY Associates L.L.C, New Mexico.

-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl " | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/

Re: [rtl] Soft Real Time

[Bernhard Kuhn]

Herman Bruyninckx wrote:

> We have a control problem in which we need a simple controller to run at
> preferably 30 000 Hz... So, keeping everything in cache is really needed...

30 KHz is ok, as long as some events can be missed
or jitters in the range of the period are ok.
Otherwise you might run into problems with
latencies using Host-to-PCI bridges (but who knows?) ...
So, IMHO, it is more wise to design a dedicated
controller unit for your application ...

Bernhard
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl " | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/

Re: [rtl] Soft Real Time

[Herman Bruyninckx]

On Sat, 24 Jun 2000, Bernhard Kuhn wrote:

> Herman Bruyninckx wrote:
> 
> [ Asymetric Multiprocessing with Linux and another RTOS ]
> 
> > Sounds great, for things such as machine control, where you need a known
> > and invarying number of small tasks that just have to run very fast.
> 
> That´s not the point! RT-Linux (and RTAI as well) are just fine for this
> purpose - except the latencies caused by potential cache misses are too
> big (usualy < 5 µs - IMHO, that´s quite ok for advanced machine control,
> but who knows?). 
We have a control problem in which we need a simple controller to run at
preferably 30 000 Hz... So, keeping everything in cache is really needed...

--
[EMAIL PROTECTED] (Ph.D.)Fax: +32-(0)16-32 29 87
Dept. Mechanical Eng., Div. PMA, Katholieke Universiteit Leuven, Belgium

-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl " | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/

Re: [rtl] Soft Real Time

[Bernhard Kuhn]

Herman Bruyninckx wrote:
> 

[ Asymetric Multiprocessing with Linux and another RTOS ]

> Sounds great, for things such as machine control, where you need a known
> and invarying number of small tasks that just have to run very fast.

That´s not the point! RT-Linux (and RTAI as well) are just fine
for this purpose - except the latencies caused by potential
cache misses are to big (usualy < 5 µs - IMHO, that´s quite ok
for advanced machine control, but who knows?). On the
other hand, you could virtualy any other open-source OS run
in parallel with linux. People with huge experience with
the other operating systems could move to an linux-enhanced
environment without changing their mind ... it would
even enable other makers of operating systems to
modifiy their os so that it can run in parallel.
The only point is resource management: you have
to tell the other os explicitly which PCI-cards
and memory areas it can use ... (imagine BEOS with
it´s own GFX-card running in parallel with linux).


> > If there are enough people out there, interessted in that idea, we could
> > revival the project.
> I'm interested! I guess the same thing would work with ecos too?
>  ()

Very likly ... you just have to bootstrap the second
processor and tell the upcoming os which recources it
is allowed to use ...

The first step is already somewhat done ... but right
now, it´s an awfull hack ... we (three engineerers)
only spend 8 hour on the problem a year ago :-)

I will have a look for the kernel-diffs we produced:
actually i can´t find them on my local disk drive - i
very likely have to ask my former colleagues
for the patches ... but i suggest to withdraw
the code, begining from scratch, anyway


The old code realy was a hack:

The SMP-Kernel is coming up as usual. Then
the second processor jumps to the desired
code via a dedicated "trampoline", and
the it is disabled in the
linux processor list just befor the
kernel enters the scheduler (thus
all linux-tasks will have to start on the
first processor)


The better solutions would be:

The kernel comes up in UP mode or
with the kerneloptions "numcpus=1" and "mem=m".
Later, a kernel module could wake up the still
sleeping second processor: just have a look at smp.c,
the wakeup-code could be copied easily.

The module has a mandatory parameter like "start=0x7F0"
(if you have reserved the top 1 Mbyte for the other
os on a machine with 128 Mbyte of memory)
Of course, you first had to copy the code of the
second os to this location in some way, maybe with
another kernel module using the /proc-fs)

In this way, you even won´t have to modify the kernel,
and the system would just work with any Distribution ...

But there also could be a gerneric
interface in the kernel to wake up the second
processor, using the /proc-filesystem, for
example:

echo 0x7F0 > /proc/amp/cpu1/start

In this way, you don´t have to copy
the wake-up code from smp.c, but i am not
sure, if this is the simpler way to do ...
(i´d like to prefer the first way)


BTW: The two operating system could easly talk to
each other, using shared memory and the APICs
(simulated interrupts, etc.)

just an idea ...

comments?


Bernhard
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl " | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/

Re: [rtl] Soft Real Time

[Herman Bruyninckx]

On Sat, 24 Jun 2000, Bernhard Kuhn wrote:

[...]
> A year ago, me and some (former) collegues had the following idea: on an
> SMP machine, Linux could run in non-SMP-mode on one processor, while
> RTEMS is using the other processor. Depending on the application, the
> whole RTEMS-stuff would fit into 512 KByte of memory, an thus fitting
> completly into the L2-Cache of a Pentium II.

Sounds great, for things such as machine control, where you need a known
and invarying number of small tasks that just have to run very fast.
[...]
> If there are enough people out there, interessted in that idea, we could
> revival the project.
I'm interested! I guess the same thing would work with ecos too?
 ()


--
[EMAIL PROTECTED] (Ph.D.)Fax: +32-(0)16-32 29 87
Dept. Mechanical Eng., Div. PMA, Katholieke Universiteit Leuven, Belgium


-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl " | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/

Re: [rtl] Soft Real Time

[Bernhard Kuhn]

al lykken wrote:

> The problem is that when another process is started, any access to disk,
> etc I blow my frame, where I get burps out to 10 - 30ms.

IMHO, 30 ms is rather good for a non rt-kernel :-)

If 1 ms is good enough for your application, then
somewhat like Linux/RT (AKA Linux/RK, see www.timesys.com, Hi Raj!)
or KU-RT (http://www.ittc.ukans.edu/kurt/, Hi, Douglas!) would fit
your needs. As these projects (indended for x86, AFAIK) are just
modifing  the kernel-scheduler, there is at least a good chance
that they could apply to PPC as well ...

Another chance: have a look at
http://people.redhat.com/mingo/lowlatency-patches/
http://people.redhat.com/mingo/scheduler-patches/

Sounds good, but don´t ask me what these patches
are doing :-)

Next posibility: give RTL3.0 a chance, get the source code,
modifiy it, until it fits you needs and send the patches
back to Victor :-)
BTW: is RTL3.0 for PPC ready for SMP?


The last Chance would result in a new real-time project:

A year ago, me and some (former) collegues had
the following idea: on an SMP machine, Linux could
run in non-SMP-mode on one processor, while
RTEMS is using the other processor. Depending
on the application, the whole RTEMS-stuff would
fit into 512 KByte of memory, an thus fitting
completly into the L2-Cache of a Pentium II.

We played around a little bit and succeeded to
start a simple program (toggling bits on the
parallel-port) on the second processor,
while linux was running on the first.
We just had to modify about 40 lines in the
Kernel to do so ...

If there are enough people out there, interessted
in that idea, we could revival the project.
(AFAIR, RTEMS runs on PPC as well).

Bernhard
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl " | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/

[rtl] Soft Real Time

[al lykken]

I'm involved in a new project where we plan to use dual Power PC Synergy
SBCs running
Yellow Dog LINUX.  Since RT Linux doesn't seem to ready for prime time I
have been trying
to do deterministic scheduling with the existing system, with some
success.  So far I:

1.Changed my HZ from 100 to 1000
2.Set the running thread priority to 90 with sched_setscheduler
3.Locked the task in memory with mlockall
4.I used the interval timer, setitimer to do my scheduling

I am able to get tasks to down to ~1 ms.  And as lone as nothing else is

going on it is solid as a rock

The problem is that when another process is started, any access to disk,
etc I blow my frame,
where I get burps out to 10 - 30ms.

Is there anything else I might do to make my task more deterministic and
is there any hope for RT Linux
with Synergy (PPC).

Thanks..Al


-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl " | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/