Re: [rtl] Soft Real Time

[William Montgomery]

Hi Bernhard,

Interesting comments on PCI bus latencies.
Do you (or anyone on this list) have any sample code or other
data on programming the PCI bridge chips in the way you describe?

Wm

On Sun, 25 Jun 2000, Bernhard Kuhn wrote:

> Herman Bruyninckx wrote:
> 
> > I have a dual Pentium III 700Mhz, and I wanted to investigate how it
> > compares to DSP performance, when everything can be kept in cache.
> 
> Keeping things in cache is only half of the way ... the bigger
> problem is to bother around with latencies caused by
> the pci-architecture ... with modern chip-sets, it´s hard to
> tell what exactly is going on ... several things have to
> be taken into account:
> 
> 1. CPU to Host-Bridge latency: you will have to disable caching and
>write combinig in case your I/O card is memory mapped.
>Even then, you have latencies when sharing the CPU-bus
>with another processor.
> 
> 2. Host-Bridge to PCI-Bus latency: you might disable the
>read/write fifo (usual depth: 64) of the Host-Bridge.
> 
> 3. you realy should disable PCI-Burst operations, which
>can by up to 64 cycles. Otherwise having, for example,
>five PCI-device, the arbitration could go up to 10 µs in
>this stage.
> 
> 4. Latencys caused be the I/O-Card itself
> 
> 
> If a worst case latency of about 20 µs are just fine for
> your application, then stay with RTL and standard settings.
> 
> Otherwise it´s going deep into details:
> 
> One solution could be the mentioned idea with the second
> OS on the second CPU.
> 
> Another method would be to disallow any kind of linux-kernel
> activities on the second processor. Some times ago,
> i took a look into the code of the kernel scheduler ...
> it should be feasabel to keep away user-space processes
> and kernel threads from the second processor by modifiying
> the code a little bit.
> Linux-Interrupts can be directed the the first CPU
> by simply reprograming the I/O-APIC, as far as i got it.
> So the second CPU should completly belongs to your
> RTL-application, that even could fit into the L1-Cache
> of the CPU.
> 
> If this didn´t scared you then go reading on:
> 
> Getting rid of the PCI-latencies is a little bit more
> difficult: You could use the three-wire APIC protocoll to
> attach a special I/O-Card directly onto the CPU.
> The maximum latency/jitter is less then one microsecond in
> this case, but then you have to bother around with
> a 100 MHz serial line, simulation a local APIC ...
> 
> Just a dream ...
> 
> 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] ---
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

[Raymond Knopp]

I would be interested in testing this experimental version.  We're
using a dual PII machine with RTLinux and doing heavy DSP in a 
real-time thread.  I'd like to try dedicating a
CPU to the DSP stuff.

Thanks for any help.

Raymond Knopp


[EMAIL PROTECTED] wrote:
> 
> We have an experimental RTL V3 with an option to turn off Linux
> on one PC. Measured latencies are very low -- but this is early code.
> If you are interested in testing please send email to me.
> 
> On Sun, Jun 25, 2000 at 08:42:57PM +0200, Bernhard Kuhn wrote:
> > Herman Bruyninckx wrote:
> >
> > > I have a dual Pentium III 700Mhz, and I wanted to investigate how it
> > > compares to DSP performance, when everything can be kept in cache.
> >
> > Keeping things in cache is only half of the way ... the bigger
> > problem is to bother around with latencies caused by
> > the pci-architecture ... with modern chip-sets, it´s hard to
> > tell what exactly is going on ... several things have to
> > be taken into account:
> >
> > 1. CPU to Host-Bridge latency: you will have to disable caching and
> >write combinig in case your I/O card is memory mapped.
> >Even then, you have latencies when sharing the CPU-bus
> >with another processor.
> >
> > 2. Host-Bridge to PCI-Bus latency: you might disable the
> >read/write fifo (usual depth: 64) of the Host-Bridge.
> >
> > 3. you realy should disable PCI-Burst operations, which
> >can by up to 64 cycles. Otherwise having, for example,
> >five PCI-device, the arbitration could go up to 10 µs in
> >this stage.
> >
> > 4. Latencys caused be the I/O-Card itself
> >
> >
> > If a worst case latency of about 20 µs are just fine for
> > your application, then stay with RTL and standard settings.
> >
> > Otherwise it´s going deep into details:
> >
> > One solution could be the mentioned idea with the second
> > OS on the second CPU.
> >
> > Another method would be to disallow any kind of linux-kernel
> > activities on the second processor. Some times ago,
> > i took a look into the code of the kernel scheduler ...
> > it should be feasabel to keep away user-space processes
> > and kernel threads from the second processor by modifiying
> > the code a little bit.
> > Linux-Interrupts can be directed the the first CPU
> > by simply reprograming the I/O-APIC, as far as i got it.
> > So the second CPU should completly belongs to your
> > RTL-application, that even could fit into the L1-Cache
> > of the CPU.
> >
> > If this didn´t scared you then go reading on:
> >
> > Getting rid of the PCI-latencies is a little bit more
> > difficult: You could use the three-wire APIC protocoll to
> > attach a special I/O-Card directly onto the CPU.
> > The maximum latency/jitter is less then one microsecond in
> > this case, but then you have to bother around with
> > a 100 MHz serial line, simulation a local APIC ...
> >
> > Just a dream ...
> >
> > 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/
> 
> --
> -
> 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/

-- 
---
Dr. Raymond Knopp
Mobile Communications Laboratory
EPFL, IN-R Ecublens
CH-1015 Lausanne
SWITZERLAND

Tel: (+41) 21 693 5657
Fax: (+41) 21 693 4312
Email: [EMAIL PROTECTED]

-- [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

[jlhagen]

Stuart Hughes <[EMAIL PROTECTED]>@fsmlabs.com on 06/27/2000 05:03:48
AM

Sent by:  [EMAIL PROTECTED]


To:   [EMAIL PROTECTED]
cc:   Mike Cravens <[EMAIL PROTECTED]>, [EMAIL PROTECTED], Don
  Mcneill <[EMAIL PROTECTED]>, Bernhard Kuhn
  <[EMAIL PROTECTED]>, [EMAIL PROTECTED]

Subject:  Re: [rtl] Soft Real Time


[EMAIL PROTECTED] wrote:
>
> On Mon, Jun 26, 2000 at 01:18:21PM -0500, Mike Cravens wrote:
> > Could you encourage more participation in the porting  process by
others
> > interested in keeping the source open?
> >
> > If you close the source,  I might as well use VxWorks.
>
> I am not closing the source. Please note that there are new GPL releases
> of RTLinux on our web site nearly every week. We have a long
> track record of delivering GPL code. Longer than anyone else in this
> area, by some years.
>
> > Many people are just arriving at the real-time and embedded party.
> >
> > Getting people to contribute commits them in ways beyond money and
economics.
> >
> > There are some things that die if you hold them too tightly.
>
> Contributed source and ports are great. Please send 'em.
> What we've found is that most RTLinux users want to work on their
> own apps.  RT kernel code is really specialized.
>  If you look at the credits file sent with RTLinux, you will
> see that there are some exceptions -- and I, for one, really appreciate
them.
> Tomasz, Jerry, and others have been critical. What I have rejected,
> and will continue to reject are changes that I think are technically
> wrong, poorly done, or violate the base paradigm. An advantage of
> open source is that others who disagree are free to pursue their own
> path. And if their ideas turn out to be good, we may even change our
> minds. A good example of how this works is the Linux fbcon component
> that came after a conceptually similar but weak alternate method
> was rejected.

Hi Victor,

If RTLinux is truly GPL, can you state clearly that the patent described
in the RTLinux distribution will only be used defensively, and not as a
means to:

a) place restrictions on derivative works

b) to force royalty payments from either RTLinux or derivatives.

Regards, Stuart
-- [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/


xxx 142 % cat COPYRIGHT
RTLinux (RT-Linux)
is Copyright VJY Associates LLC 1999 except where copyright is
declared in individual code files. The unmodified Linux and contributed
code remains the copyright of the authors.

RTLinux is a trademark of VJY Associates LLC.
RTLinux is protected under US Patent 5,995,745.


This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.

This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
GNU General Public License for more details.

You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA

-- /accts/xx/linux/rtlinux/FMS_Version2.2/rtlinux-2.2 --
xxx 143 % cat PATENT
US Patent 5,995,745 covers the basic mechanism underlying RTLinux.
There is a royalty free license of this patent for use with the combined
open source GPL licensed versions of the Linux  operating system released
by Linus Torvalds and the RTLinux RealTime Linux operating system released by
VJY Associates LLC.

PATENT FAQ:

RTLinux will continue to be released in open source. No royalties
are needed to use RTLinux or to run programs on RTLinux.


I believe the included files already answer those questions. Further, what
is with the persistent animosity towards Victor and his work? The technical
arguments presented on this list are excellent but the general slinging of
mud Victor's way is getting old.

JH


-- [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

[Stuart Hughes]

[EMAIL PROTECTED] wrote:
> 
> On Mon, Jun 26, 2000 at 01:18:21PM -0500, Mike Cravens wrote:
> > Could you encourage more participation in the porting  process by others
> > interested in keeping the source open?
> >
> > If you close the source,  I might as well use VxWorks.
> 
> I am not closing the source. Please note that there are new GPL releases
> of RTLinux on our web site nearly every week. We have a long
> track record of delivering GPL code. Longer than anyone else in this
> area, by some years.
> 
> > Many people are just arriving at the real-time and embedded party.
> >
> > Getting people to contribute commits them in ways beyond money and economics.
> >
> > There are some things that die if you hold them too tightly.
> 
> Contributed source and ports are great. Please send 'em.
> What we've found is that most RTLinux users want to work on their
> own apps.  RT kernel code is really specialized.
>  If you look at the credits file sent with RTLinux, you will
> see that there are some exceptions -- and I, for one, really appreciate them.
> Tomasz, Jerry, and others have been critical. What I have rejected,
> and will continue to reject are changes that I think are technically
> wrong, poorly done, or violate the base paradigm. An advantage of
> open source is that others who disagree are free to pursue their own
> path. And if their ideas turn out to be good, we may even change our
> minds. A good example of how this works is the Linux fbcon component
> that came after a conceptually similar but weak alternate method
> was rejected.

Hi Victor,

If RTLinux is truly GPL, can you state clearly that the patent described
in the RTLinux distribution will only be used defensively, and not as a
means to:

a) place restrictions on derivative works

b) to force royalty payments from either RTLinux or derivatives.

Regards, Stuart
-- [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 Mon, Jun 26, 2000 at 01:18:21PM -0500, Mike Cravens wrote:
> Could you encourage more participation in the porting  process by others
> interested in keeping the source open?
> 
> If you close the source,  I might as well use VxWorks.

I am not closing the source. Please note that there are new GPL releases
of RTLinux on our web site nearly every week. We have a long
track record of delivering GPL code. Longer than anyone else in this
area, by some years.


> Many people are just arriving at the real-time and embedded party.
> 
> Getting people to contribute commits them in ways beyond money and economics.
> 
> There are some things that die if you hold them too tightly.


Contributed source and ports are great. Please send 'em.
What we've found is that most RTLinux users want to work on their
own apps.  RT kernel code is really specialized.
 If you look at the credits file sent with RTLinux, you will
see that there are some exceptions -- and I, for one, really appreciate them.
Tomasz, Jerry, and others have been critical. What I have rejected, 
and will continue to reject are changes that I think are technically
wrong, poorly done, or violate the base paradigm. An advantage of 
open source is that others who disagree are free to pursue their own
path. And if their ideas turn out to be good, we may even change our 
minds. A good example of how this works is the Linux fbcon component
that came after a conceptually similar but weak alternate method
was rejected.


> Having source is a security blanket that we can pack our own parachute ,  if
> need be,  but we would rather focus on our areas of expertise as a
> corporation,  and get help in other areas.

Of course. The commercial advantage of Linux/Open-Source is exactly
this: the balance of power shifts from the controlling closed source
vendor. Our customers have the advantage of being able to get support
from someone else, or do some work internally, or ...
This means we have to deliver or get replaced, and we don't mind that
bargain at all. However, because customers now have more power, they
have to be careful to think things through and decide on the implications
of choosing one vendor over another.  For example, paying a vendor
for a product delivered by Debian, while not putting any money back
into Debian may be a self-defeating strategy.  

> You might want to get your investors to read "Under the Radar,  by Red Hat's
> Robert Young.  The part where he was talking to Intel money people about giving
> away software was both humorous and informative.

When RedHat (or Heinz ketchup!)  posts a profit this will be
a more persuasive argument.

I don't want to 
overemphasize the difficulties. We are still having a good time here --
and we are breaking even. But even a calm, easygoing, person like myself
can lose his temper now and then.  And at ELC, I talked to a potential
investor who asked me precisely this question inspired by talks in which
Debian invented technology was being advertised as proprietary.  A
somewhat grumpy, low-sleep email followed. Don't read too much into it.


-- [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

[Mike Cravens]

Could you encourage more participation in the porting  process by
others interested in keeping the source open?
If you close the source,  I might as well use VxWorks.
Many people are just arriving at the real-time and embedded party.
Getting people to contribute commits them in ways beyond money and economics.
There are some things that die if you hold them too tightly.
Our biggest concern where I work is that our vendors of "software" --
usually meaning services -- will not be able to keep up with our demands
and we will have to do work here on infrastructure that we would rather
someone else provided.
Having source is a security blanket that we can pack our own parachute
,  if need be,  but we would rather focus on our areas of expertise
as a corporation,  and get help in other areas.
We have several time " bought " software that we though included a specific
port or "Board Support Package",  complete with development environments
and support contracts,   only to be told that the BSP was not
a product,  just an unsupported example,  that the tool chain
was now obsolete,  and we must change in mid project,  and that
our support contract did not cover getting responses in finite time, 
and that all our problems would be solved if we could suddenly sign a consulting
agreement.
You might want to get your investors to read "Under the Radar, 
by Red Hat's Robert Young.  The part where he was talking to Intel
money people about giving away software was both humorous and informative.
 
The project I current work on is an example of why having source is
important.
We needed a real-time data base package on embedded Linux node, 
and started with one we have source to for Solaris on Sparc.
The port has involved changing some kernel parameters involving things
like shared memory,  buffer queue depth,  semaphores,  etc.
In modifying these things,  I was concerned about inducing inefficiency
or bugs.
Reading kernel source led me to see the implications of our changes
and the limits on them;   I also found a latent kernel source
bug in how message related parameters are defined that would be catastrophic
in our case while not affecting users with short queue depths.
So I have avoided having my  (legal) change break existing code, 
and saved a full design cycle over just having header information, 
etc.
Also,  our project started on a closed X86  Unix which required
long cycle times through the vendor to change anything.  We cannot
meet our schedules and go through that [extended]  hoops that they
require to effect change.
So all our embedded nodes now run O/S's for which we have source.
Regards,
 
Mike
 
 
[EMAIL PROTECTED] wrote:
On Sun, Jun 25, 2000 at 10:49:11PM +0200, Bernhard
Kuhn wrote:
> [EMAIL PROTECTED] wrote:
> >
> > We have an experimental RTL V3 with an option to turn off Linux
> > on one PC. Measured latencies are very low -- but this is early
code.
> > If you are interested in testing please send email to me.
>
> Very interessting!
>
> I´d like to have a look at it, because i intend to
> modify the kernel-scheduler in the following way
> (if i ever have enough time to do so :-) )
>
> o user-spaces processes, kernel-threads and linux-interrupts
>   should be fixable to specific CPUs.
Ingo did Linux interrupts already for  2.3 x86. The others should
be easy.
BTW: We are under enormous pressure from potential funders who argue
that
we need to abandon open source entirely to keep Lineo from simply riding
us down. I expect RTAI in the future will have done PPC ports
before RTLinux and etc. I'm attempting to manouver around both this
problem
and funder demands.  We will see.
> o Additionaly to the usual time-sharing "nice-value", a
>   priority is assigned to user-space processes, resulting
>   in somewhat i would call a "hierarchical priority encoded
>   preemptiv time sharing scheduler" :-)
I have a solution to this, but [see above]
> This surely wouldn´t apply to machine control systems, but
> is intended for multimedia (happy fragging!) ... i know
> that there are several other projects out there, that care
> especialy about the second point (red linux, qlinux),
> but AFAIK, nobody cares about the first one ...
RedLinux contains RTLinux 0.9 code, I don't know the others. But [see
above]
>
> BTW: how was you talk in San Jose?
Packed. Very interesting.
--
-
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/

-- 
  Alcatel USA    Internet: [EMAIL PROTECTED]
  1000 Coit Road Plano, Texas 75075
   The opinions expressed are not those of DSC Communications, Inc 
  
  
  
  "Keep things as simple as possible,   but no simpler".   A. Einstein

Re: [rtl] Soft Real Time

[Mike Cravens]

I enjoyed Victor's presentation in San Jose last week very much. 
I also told whoever would listen,  particularly the Lineo CTO, 
that the light really went on for me about open source earlier this year, 
after about 10 years of being skeptical.
Secret code often has secret bugs,  because "All bugs are shallow
,  given enough eyes".
The fewer users of a piece of code,  the less reliable it is likely
to be.
With source available,  the bug can be discovered and fixed in
one or two cycles of the mail.
This beats semi-annual or annual " bug fix"  releases.
Regards,
Mike
 
Bernhard Kuhn wrote:
[EMAIL PROTECTED] wrote:
> BTW: We are under enormous pressure from potential funders who argue
that
> we need to abandon open source entirely to keep Lineo from simply
riding
> us down. I expect RTAI in the future will have done PPC ports
> before RTLinux and etc. I'm attempting to manouver around both this
problem
> and funder demands.  We will see.
hmm ...
I am allways wondering why customers prefer wasting
their money for licences instead paying for
good services ... that´s that basic Idea with linux
and with mechanisms like the web: any good line
of code can be reproduced million times without
any costs ... the good lines will sum up over
time and that´s it!
The earlier the pointy haired bosses get used to
this, the earlier they will understand what´s going
on: if any feature is realy interessting for
any application, then how long will it take until
somebody will reprogram the hidden code because
he needs it or just because he is courious or
doesn´t know how to spend his time in another way? :-)
If the code is too special and only applies for a few
customers, then nobody will care wether the code
is available or not ...
You know that all this rt-stuff is no rocket technology
and can be performed by a small group of people
(or even by a single person) within a few month ...
That´s why Linux scares QNX and Lynx (Ah, sorry LynuxWorks):
They are just jumping onto the open source train
like many other companies to *protect* their invests:
If somebody has published his code long befor you,
then he´s the boss. It´s more like in the
scientific world: publish or parish!
Coming back to Lineo: although it´s a really strange
company to me, they also recogniced the need to
publish their stuff ...
To sum it up: sell services, not products!
Ok, this is a little bit more sophisticated,
but as long as you can´t delete any line
of open source code, time can´t be turned
back!
just my 0.02 euro ...
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/

-- 
  Alcatel USA    Internet: [EMAIL PROTECTED]
  1000 Coit Road Plano, Texas 75075
   The opinions expressed are not those of DSC Communications, Inc 
  
  
  
  "Keep things as simple as possible,   but no simpler".   A. Einstein
 

begin:vcard 
n:cravens;mike
tel;home:(972) 423-9463
tel;work:(972) 477-7077
x-mozilla-html:TRUE
adr:;;1000 Coit Rd;Plano;Tx;75075;USA
version:2.1
email;internet:[EMAIL PROTECTED]
title:Senior Software Engineer
x-mozilla-cpt:;-10560
fn:[EMAIL PROTECTED]
end:vcard

Re: [rtl] Soft Real Time

[Bernhard Kuhn]

[EMAIL PROTECTED] wrote:

> BTW: We are under enormous pressure from potential funders who argue that
> we need to abandon open source entirely to keep Lineo from simply riding
> us down. I expect RTAI in the future will have done PPC ports
> before RTLinux and etc. I'm attempting to manouver around both this problem
> and funder demands.  We will see.

hmm ...

I am allways wondering why customers prefer wasting
their money for licences instead paying for
good services ... that´s that basic Idea with linux
and with mechanisms like the web: any good line
of code can be reproduced million times without
any costs ... the good lines will sum up over
time and that´s it!

The earlier the pointy haired bosses get used to
this, the earlier they will understand what´s going
on: if any feature is realy interessting for
any application, then how long will it take until
somebody will reprogram the hidden code because
he needs it or just because he is courious or
doesn´t know how to spend his time in another way? :-)

If the code is too special and only applies for a few
customers, then nobody will care wether the code
is available or not ...

You know that all this rt-stuff is no rocket technology
and can be performed by a small group of people
(or even by a single person) within a few month ...

That´s why Linux scares QNX and Lynx (Ah, sorry LynuxWorks):
They are just jumping onto the open source train
like many other companies to *protect* their invests:

If somebody has published his code long befor you,
then he´s the boss. It´s more like in the
scientific world: publish or parish!

Coming back to Lineo: although it´s a really strange
company to me, they also recogniced the need to
publish their stuff ...


To sum it up: sell services, not products!

Ok, this is a little bit more sophisticated,
but as long as you can´t delete any line
of open source code, time can´t be turned
back!

just my 0.02 euro ...

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

[yodaiken]

On Sun, Jun 25, 2000 at 10:49:11PM +0200, Bernhard Kuhn wrote:
> [EMAIL PROTECTED] wrote:
> > 
> > We have an experimental RTL V3 with an option to turn off Linux
> > on one PC. Measured latencies are very low -- but this is early code.
> > If you are interested in testing please send email to me.
> 
> Very interessting!
> 
> I´d like to have a look at it, because i intend to
> modify the kernel-scheduler in the following way
> (if i ever have enough time to do so :-) )
> 
> o user-spaces processes, kernel-threads and linux-interrupts
>   should be fixable to specific CPUs. 

Ingo did Linux interrupts already for  2.3 x86. The others should be easy.

BTW: We are under enormous pressure from potential funders who argue that 
we need to abandon open source entirely to keep Lineo from simply riding
us down. I expect RTAI in the future will have done PPC ports
before RTLinux and etc. I'm attempting to manouver around both this problem
and funder demands.  We will see.

> o Additionaly to the usual time-sharing "nice-value", a
>   priority is assigned to user-space processes, resulting
>   in somewhat i would call a "hierarchical priority encoded
>   preemptiv time sharing scheduler" :-)

I have a solution to this, but [see above]

> This surely wouldn´t apply to machine control systems, but
> is intended for multimedia (happy fragging!) ... i know
> that there are several other projects out there, that care
> especialy about the second point (red linux, qlinux),
> but AFAIK, nobody cares about the first one ...


RedLinux contains RTLinux 0.9 code, I don't know the others. But [see above]

> 
> BTW: how was you talk in San Jose?

Packed. Very interesting. 


-- 
-
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]

[EMAIL PROTECTED] wrote:
> 
> We have an experimental RTL V3 with an option to turn off Linux
> on one PC. Measured latencies are very low -- but this is early code.
> If you are interested in testing please send email to me.

Very interessting!

I´d like to have a look at it, because i intend to
modify the kernel-scheduler in the following way
(if i ever have enough time to do so :-) )

o user-spaces processes, kernel-threads and linux-interrupts
  should be fixable to specific CPUs. 

o Additionaly to the usual time-sharing "nice-value", a
  priority is assigned to user-space processes, resulting
  in somewhat i would call a "hierarchical priority encoded
  preemptiv time sharing scheduler" :-)

This surely wouldn´t apply to machine control systems, but
is intended for multimedia (happy fragging!) ... i know
that there are several other projects out there, that care
especialy about the second point (red linux, qlinux),
but AFAIK, nobody cares about the first one ...

BTW: how was you talk in San Jose?

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

[yodaiken]

We have an experimental RTL V3 with an option to turn off Linux
on one PC. Measured latencies are very low -- but this is early code.
If you are interested in testing please send email to me.



On Sun, Jun 25, 2000 at 08:42:57PM +0200, Bernhard Kuhn wrote:
> Herman Bruyninckx wrote:
> 
> > I have a dual Pentium III 700Mhz, and I wanted to investigate how it
> > compares to DSP performance, when everything can be kept in cache.
> 
> Keeping things in cache is only half of the way ... the bigger
> problem is to bother around with latencies caused by
> the pci-architecture ... with modern chip-sets, it´s hard to
> tell what exactly is going on ... several things have to
> be taken into account:
> 
> 1. CPU to Host-Bridge latency: you will have to disable caching and
>write combinig in case your I/O card is memory mapped.
>Even then, you have latencies when sharing the CPU-bus
>with another processor.
> 
> 2. Host-Bridge to PCI-Bus latency: you might disable the
>read/write fifo (usual depth: 64) of the Host-Bridge.
> 
> 3. you realy should disable PCI-Burst operations, which
>can by up to 64 cycles. Otherwise having, for example,
>five PCI-device, the arbitration could go up to 10 µs in
>this stage.
> 
> 4. Latencys caused be the I/O-Card itself
> 
> 
> If a worst case latency of about 20 µs are just fine for
> your application, then stay with RTL and standard settings.
> 
> Otherwise it´s going deep into details:
> 
> One solution could be the mentioned idea with the second
> OS on the second CPU.
> 
> Another method would be to disallow any kind of linux-kernel
> activities on the second processor. Some times ago,
> i took a look into the code of the kernel scheduler ...
> it should be feasabel to keep away user-space processes
> and kernel threads from the second processor by modifiying
> the code a little bit.
> Linux-Interrupts can be directed the the first CPU
> by simply reprograming the I/O-APIC, as far as i got it.
> So the second CPU should completly belongs to your
> RTL-application, that even could fit into the L1-Cache
> of the CPU.
> 
> If this didn´t scared you then go reading on:
> 
> Getting rid of the PCI-latencies is a little bit more
> difficult: You could use the three-wire APIC protocoll to
> attach a special I/O-Card directly onto the CPU.
> The maximum latency/jitter is less then one microsecond in
> this case, but then you have to bother around with
> a 100 MHz serial line, simulation a local APIC ...
> 
> Just a dream ...
> 
> 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/

-- 
-
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 09:04:26AM -0700, al lykken wrote:

[synergy ppc boards]
> I have not spent a lot of time getting RTLinux working because I was told that
> it was not ready.
> I will certainly re-visit the issue after all the comments.

We had a joint project with Synergy to make RTL run on the Synergy
boards. Synergy later decided to focus their attention on the hardware and 
we got distracted with other projects, so we left it less than complete.
However, PPC RTLinux worked first on UP Synergy boards.

-
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:

> I have a dual Pentium III 700Mhz, and I wanted to investigate how it
> compares to DSP performance, when everything can be kept in cache.

Keeping things in cache is only half of the way ... the bigger
problem is to bother around with latencies caused by
the pci-architecture ... with modern chip-sets, it´s hard to
tell what exactly is going on ... several things have to
be taken into account:

1. CPU to Host-Bridge latency: you will have to disable caching and
   write combinig in case your I/O card is memory mapped.
   Even then, you have latencies when sharing the CPU-bus
   with another processor.

2. Host-Bridge to PCI-Bus latency: you might disable the
   read/write fifo (usual depth: 64) of the Host-Bridge.

3. you realy should disable PCI-Burst operations, which
   can by up to 64 cycles. Otherwise having, for example,
   five PCI-device, the arbitration could go up to 10 µs in
   this stage.

4. Latencys caused be the I/O-Card itself


If a worst case latency of about 20 µs are just fine for
your application, then stay with RTL and standard settings.

Otherwise it´s going deep into details:

One solution could be the mentioned idea with the second
OS on the second CPU.

Another method would be to disallow any kind of linux-kernel
activities on the second processor. Some times ago,
i took a look into the code of the kernel scheduler ...
it should be feasabel to keep away user-space processes
and kernel threads from the second processor by modifiying
the code a little bit.
Linux-Interrupts can be directed the the first CPU
by simply reprograming the I/O-APIC, as far as i got it.
So the second CPU should completly belongs to your
RTL-application, that even could fit into the L1-Cache
of the CPU.

If this didn´t scared you then go reading on:

Getting rid of the PCI-latencies is a little bit more
difficult: You could use the three-wire APIC protocoll to
attach a special I/O-Card directly onto the CPU.
The maximum latency/jitter is less then one microsecond in
this case, but then you have to bother around with
a 100 MHz serial line, simulation a local APIC ...

Just a dream ...

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 [EMAIL PROTECTED] wrote:

> On Sun, Jun 25, 2000 at 12:04:36AM +0200, 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...
> 
> Do you really need SMP _PowerPC_ ? If not we have something to beta test
> on SMP x86.
> 
We don't need PowerPC (that part of the thread did not apply to my reply).
I have a dual Pentium III 700Mhz, and I wanted to investigate how it
compares to DSP performance, when everything can be kept in cache.

--
[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

[al lykken]

Thanks for all the comments and suggestions.

Bernard:1)I tried both the patches you mentioned and they had minimal
impact.
 2)I am checking with the KURT group about their progress
with PPC
 Thanks

Bill:   Sorry if I sounded like I was blasting RTLinux.  I have been using
RTLinux  for the
past three years in several projects and love it.  As for the PPC, our group
went through a lengthy
SBC evaluation and have picked the Synergy PPC as the board of choice and we
WILL
use it.  We have tentatively selected the dual PPC version using SMP but I
feel for the kind of work
we plan on doing and memory contention a single CPU version will work just
fine.  It appears
that with the horse-power of the PPC that our bottle-neck will be I/O so
multiple CPUs will not help.
I have not spent a lot of time getting RTLinux working because I was told that
it was not ready.
I will certainly re-visit the issue after all the comments.

We will have three or four Synergy SBCs running in a VMEbus chassis.  The
boards that require
RT scheduling will be running out of ramdisk and NFS mounted to a system disk.

Again, Thanks for all the comments, and I'll experiment with some of the ideas
mentioned.

Al


Bill Crum wrote:

> Sorry about earlier message, forgot you were talking about the Dual PPC.
> Good luck
> Bill
>
> - Original Message -
> From: al lykken <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Saturday, June 24, 2000 3:27 PM
> Subject: [rtl] Soft Real Time
>
> >
> >
> > > --
> > > From: al lykken[SMTP:[EMAIL PROTECTED]]
> > > Sent: Saturday, June 24, 2000 11:27:46 AM
> > > To: [EMAIL PROTECTED]
> > > Subject: [rtl] Soft Real Time
> > > Auto forwarded by a Rule
> > >
> > 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/

-- [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

[Erwin Rol]

Bernhard Kuhn wrote:
> 
> 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).

I am interested, altough for x86 not PowerPC.

- Erwin




> 
> 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] ---
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]

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/