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 <Your_email>" | 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 <Your_email>" | 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 <Your_email>" | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/
