On Wed, Jul 18, 2001 at 10:58:35PM -0700, [EMAIL PROTECTED] wrote:
>
> ... we are planning to replace VxWorks with linux. ...
>
A few months ago I have looked at interrupt latencies on MVME2307 (300MHz
PPC604) using a fancy digital scope. I compared the VxWorks 5.4 mv2304 BSP
and a 2.4.2ish snapshot of linuxppc. The interrupt source was an external
digital I/O VME board, so my interrupt was routed via the Universe-II
vme-pci bridge and was handled by a custom universe-II device driver.
I looked at two times- the time between the input interrupt pulse
and the time of the output pulse generated from the interrupt handler
("interrupt-level pulse") and the time between the "interrupt-level" pulse
and the output pulse generated from the user-level application (the
"user-level" pulse).
This is what I saw:
1) average "interrupt-level" time was slightly better in linux because
my custom driver did less work compared to the vxworks interrupt handler.
The numbers were roughly (from my memory) 10-15 usec (micro-seconds)
for both.
2) average "user-level" time was much better in vxworks because vxworks
does not have to do a context switch. In linux I used
two system calls (select() and read()) to emulate the vxworks semTake()
with a timeout. The numbers were roughly (from my memory) 20 us for
vxworks and 30-40 us for linux.
Then, a surprise:
3) linux had a much smaller *variance* on both times!
For vxworks, both "interrupt-level" and "user-level" times were all over
the place, especially when there was any significant network activity.
I saw delays of more than 100 us, pretty amazing for a "real-time"
operating system. (and this is after the upgrade from vxworks-5.3
and after vxworks supposedly fixed the PPC BSP scheduler bug where
they sheduled the wrong task after returning from an interrupt. Things
were much worse before).
For linux, both times stayed pretty much the same all the time,
within a few microseconds, no bizarre 100 us delays, thank you very much.
My guess on the extreme "interrupt-level" time variance is that
the vxworks ethernet driver is disabling interrupts for much longer
than the linux ethernet driver (the MVME2300 series use the DEC Tulip
ethernet chip).
My guess on the extreme "user-level" time variance is that my user-level
task is not getting scheduled immediately after the universe-II
interrupt handler returns. Either the PPC scheduler bug is not really
fixed, or there is interference from the netTask.
Conclusions:
1) vxworks is generally faster, but their crappy networking
implementation degrades (destroys) their real-time performance.
2) linux is generally slower in getting interrupts to the user-level program,
but the real-time performance is more consistent.
3) on the extremely minimalistic MVME2300-series computer with only
two interrupt sources (vme and ethernet), the generic linux performs
quite "real-time". I would guess that with more interrupt sources
(serial ports, mice, disks, etc), one would want to use RtLinux to
handle the "real-time" interrupts.
--
Konstantin Olchanski
Email: [EMAIL PROTECTED]
Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada
----- End of forwarded message from [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/
