Phil said:
Second, I am running RTL very successfully on a 486, 66MHz, 32Mb but want to
upgrade the hardware. The project involves reading some (APDs) photon counters
at rates up to tens of kHz (if we can) and manipulating the incoming signals
(which might be equally spaced in time and mighht not) to provide position
demands for a (tip-tilt) mirror (at several kHz).
Phil, I would keep the user interface entirely on another machine (not just another
CPU). This isolates the Peak CPU/DISK/Memory loads required by the the windowing
system from the RTL part.
I would assume that two RT tasks would be running : one for gathering and the other
for computing output position. These would both run under RT-linux on "box #1"
Network 2 machines and allow the user interface to run on a second (possibly
non-RTlinux ) machine.
The user interface machine can then control and monitor the RT machine via the
network. PS I am assuming that large data flows are not required to the user
interface or disks!!
1. Is patching the kernel for SMP as easy as vanilla Linux?
2. Is anyone running a similar configuration and are there any gotchas?
3. How well does the SMP RT-Linux (that's a bit of a mouthful) perform?
4. Are there any (unusual) software issues with going to SMP RT-Linux in
this environment?
Thanks in advance for any advice you might be able to give.
Avoid all the hassles above and stick with a Pair of networked uni-processors. You
only want Dual processors when there is a significant data bandwidth required between
the two processes. In that case the fast shared ram allows for quick communication
between them. I don't think your application demands that between the user interface
and the control code (Most user interfaces do not). On the other hand a DUAL
processor might be
good for splitting the control tasks. One for gathering , the other for control ( i.e
if the tasks are seperable and
can be parcelled out to the two processors).
The seperation onto two "boxes" gives several benefits:
1) crash protection of the user interface. (it is running on another computer NOT on
the RT control BOX)
2) Quicker reboots during development: since RT driver crashes do not kill the user
interface.
3) lower load on the RT CPU resulting in less interupt latency.
4) Perhaps your RT application might THEN fit inside L2 cache completely and then
never be "cached out" see
other rt-linux mail for details... ( This can be true of DUAL CPU's but on-chip L2
is usually smaller ( though faster) than the on MotherBoard caches ) this improves
interupt response time.
5)Timing issues are less likely and are easier to debug on a lightly loaded RT CPU. (
caution: converse is also true: Bugs that went un-noticed under light load can jump
out if you increase the load on the RT CPU, always test with a higher than expected
load !!)
dave
--- [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/
