| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 8881.1 | See Note 7240 | RHETT::PARKER | | Wed Feb 19 1997 11:03 | 12 |
|
Julian,
You should check out the Digital UNIX realtime performance report
described in note 7240. Depending on the amount of time the interrupt
service routine takes, you may indeed want to check into VxWorks for
this project. The requirements sound fairly ambitious for Digital
UNIX in multiuser mode. It's really hard to say without more specifics.
Lee
|
| 8881.2 | could be a bit ambitious? | BBPBV1::WALLACE | john wallace @ bbp. +44 860 675093 | Thu Feb 20 1997 05:42 | 40 |
| Hi Julian,
As described, this sounds very ambitious for either UNIX or VxWorks.
Although VxWorks interrupt latencies are more *predictable* than UNIX,
they aren't actually that much smaller. The report mentioned in .1 has
figures. From memory, we'll be talking 5-10 uS between interrupt
occurring and first instruction of driver being executed, which is a
big part of your 17uS between interrupts and leaves very little time
for processing in the driver or for real application work.
Obviously a process-to-process context switch takes a whole lot longer
(again, both with VxWorks and UNIX). If you have lots of those going on
too you have another problem. A thread to thread context switch is
substantially quicker. Details in the report.
DMCC/Lego and 2100/VME are *very* different things.
I thought the 2100/VME was end of life ? (It's a Sable with a VME crate
instead of the EISA bus, courtesy of CSS).
DMCC/Lego is Digital OEM/E+RT group's entry into the growing "passive
backplane PCI Industrial Computer" market. More info in VTX IR (search
for Modular Computing in title), or at
http://www.digital.com/info/oem
(or at ayjen1::modular).
What do you mean by an "interrupt accelerator board" ? The DMCC/Lego
stuff has an "interrupt accelerator chip" which saves having to poll to
see who interrupted in a PCI-bridged system.
If this really is a PCI-VME system, another thing to watch out for is
the per-I/O overhead on accessing the VME. It can take longer than you
expect.
According to my list, the OEM contact in Spain is Julio Ruiz in Madrid.
Does he have any local tech support who can help you on this ? You need
to tread carefully, by the sound of things!
regards
john
|
| 8881.3 | | HELIX::SONTAKKE | | Thu Feb 20 1997 12:53 | 8 |
| Is it possible that somebody meant 17.5 milliseconds?
At 17.5 microsecs interrupt rate, even the Alpha hardware will be
swamped in the PALcode alone. One would need an intelligent I/O
controller with internal buffering (similar to UART with FIFO
buffering) to handle high interrupt rate.
- Vikas
|
| 8881.4 | | RTOEU::EGAUTHIER | AUA - Another Useful Abbreviation | Fri Feb 21 1997 02:59 | 6 |
| > According to my list, the OEM contact in Spain is Julio Ruiz in Madrid.
> Does he have any local tech support who can help you on this ? You need
Technical contact for the OEM group in Madrid is Marianno Rebollo.
-Eric
|
| 8881.5 | Description in .0 => interrupt interval << 17mS | BBPBV1::WALLACE | john wallace @ bbp. +44 860 675093 | Fri Feb 21 1997 12:01 | 19 |
| Eric - thanks for the pointer.
Vikas - good suggestion - but I have a feeling that if the info in .0
is correct, they really really do need a rather high interrupt rate.
I can't say where the 17uS comes from, but .0 mentions 70 synchronous
lines, over which radar data will be arriving. If they are all active
at the same time, and all expecting their data to be processed (as
distinct from just processing those few which may be of interest), I
think something different than a single 2100 may be needed.
Maybe there's more to this than meets the eye. But this is the way it
looks to me (some of my customers do radar and I'm *assuming* this
isn't too different, we all know the risks there :-).
Which "EuroOEM Virtual Team" covers this kind of thing ? Aero/defence?
regards
john
|