| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 36.1 | SMP under VAXELN - What SMP? | BAYERN::WOLFF | Conformism is for little minds. | Thu Oct 31 1991 11:11 | 13 |
| Before I go off and explain the why's and and's, I would like to know how
you would define SMP,
Are we talking about tightly coupled SMP?
loosley coupled SMP?
Tightly coupled SMP is not possible over VMEbus. There are some hardware
specifics we don't have. Loosley coupled would be possible but is not
planned. It is also not yet planned to implement this kind of SMP on
any followon products.
Julian.
|
| 36.2 | No SMP, no can play | PRIMES::FINKELSTEIN | Dept. of Redundancy Dept. | Thu Oct 31 1991 15:29 | 8 |
| Loosley coupled is fine, what many customers want is incremental
growth. The question I need to ask you folks is, do you plan on being
competitive in this field or not? If you cannot provide SMP, do not
plan on winning against folks like Harris.
Sorry to be so blunt, but I am sitting on a $30M program that will
require SMP on a VME based system. I can do it today with the VME300
from Aeon, but I can't with our own products. This is silly.
|
| 36.3 | some SMP definitions | FOOSW6::COOK | | Fri Nov 01 1991 00:17 | 21 |
|
>Are we talking about tightly coupled SMP?
> loosley coupled SMP?
the definition I usually see is
Tightly coupled SMP - VAXELN on an 8800/6000 with multiple CPUs and shared
kernel
Closely couple SMP - VAXELN on a KA800, shared bus structure but not a
shared kernel
Loosely coupled SMP - VAXELN on NI, transparent growth and syncronization
in a distribited environment.
Are you planning closely coupled using this definition? With XMI to VME support
do you plan something like RTA using the VME bus?
al
|
| 36.4 | 1 vote for SMP | PRIMES::FINKELSTEIN | Dept. of Redundancy Dept. | Fri Nov 01 1991 01:15 | 6 |
| If we can vote on it, I would like to see us have a closely coupled
setup re .-1's definition. It would provide us the same capabilities as
Harris, but with the development environment of a VAX.
If we can add this to the phase 0 for the follow-on to the KAV30, you
have my vote. Being competitive is great, but I like to win.
|
| 36.5 | | BAYERN::WOLFF | Conformism is for little minds. | Mon Nov 04 1991 09:16 | 6 |
| To the best of my knowlege, Aeon does not have an SMP kernel. We have the board
and we have the software, and it doesn't do SMP. Also Aeon does not have the
hardware requirements to do SMP. I would be very surprised if they can do this
"today" as you said.....
Julian.
|
| 36.6 | | ZYDECO::MILLER | Don Miller | Mon Nov 04 1991 19:48 | 17 |
| I believe that Julian is correct. I have a number of customers using
the Aeon board. While I have heard the SMP rumor before, I wonder if
the term "SMP" is being abused. In V1.0 of their kernel, which ran
against Eln V4.1, they didn't even get their memory sharing routines
working properly between two VME 300s. After many delays (due mainly
to the illness of the primary developer), they came up with V1.1 in
about March, which ran against Eln V4.2 and which finally did memory
sharing correctly. "Memory sharing" means that two VME 300s could, for
example, share an interlocked queue when one system presents its memory
to the VME and the other system maps to that same memory. I believe
that they also have a mechanism for interprocessor communication
somewhat analogous to the "interprocessor doorbell" which was present
on the KA630 for use in configurations where multiple KA630s resided on
the same Qbus.
dm.
|
| 36.7 | | FOOSW6::COOK | | Mon Nov 04 1991 20:13 | 14 |
|
To avoid the SMP definition controversy, let me ask the qestion like this.
Are we saying that two or more Aeon VME300s can occupy a simgle VME bus and
communicate/synchronize with each other using standard software tools?
Are we saying that there can be only one KAV30 on a single VME? If there
can be more than one KAV30 per VME can they communicate/synchronize using
standard software tools?
al
|
| 36.8 | If they can, why can't we? | PRIMES::FINKELSTEIN | Dept. of Redundancy Dept. | Mon Nov 04 1991 20:52 | 5 |
| Let's take it a step further...
Assuming that the Aeon folks are not lying, and that they truly can do
some form of SMP. The question is can we do it with either the KAV30 or
the rtVAX300?
|
| 36.9 | | ZYDECO::MILLER | Don Miller | Mon Nov 04 1991 21:52 | 7 |
| > Are we saying that two or more Aeon VME300s can occupy a simgle VME bus and
> communicate/synchronize with each other using standard software tools?
Yes, this is currently possible with Aeon using their standard tools.
I believe that this is also possible with the KAV30.
dm.
|
| 36.10 | anything official? | FOOSW6::COOK | | Mon Nov 04 1991 23:17 | 12 |
|
> I believe that this is also possible with the KAV30.
Could we get confirmation on this from KAV30 engineering? Before I tell a
customer that he/she can do this with their KAV30s, I would like someone to
commit that it is supposed to work that way.
al
|
| 36.11 | | HERR::CROSBIE | | Tue Nov 05 1991 10:32 | 33 |
| Symmetric multi-processing (SMP) requires a single copy of the
operating system in shared memory that can be accessed (assuming that a
suitable locking mechanism can be implemented) by all of the processors
in the environment.
Symmetric multi-processing (SMP) is NOT possible with the KAV30.
To implement an SMP environment using the KAV30, we would have to use
external VMEbus memory. The KAV30 maps external VMEbus devices into
VAX I/O space, to implement a suitable locking scheme for such a
configuration it would be neccessary to perform VAX interlocked
instructions to I/O space. VAX architecture is very restrictive as to
which interlocked instructions can be performed on operands in I/O
space. Out of the seven VAX interlocked instructions ( BBSSI, BBCCI,
ADAWI, INSQHI, INSQTI, REMQHI, REMQTI), only the ADAWI instruction can
be peformed without any restrictions to operands in I/O space, BBSSI,
BBCCI, INSQHI, and INSQTI are not permitted with operands in I/O space.
It is NOT possible to implement a suitable locking mechanism using only
the ADAWI instruction.
The AEON module also maps external VMEbus devices into VAX I/O space,
so symmetric multi-processing (given the above definition) is also NOT
technically possible with the AEON module.
Multiple KAV30s in a single VMEbus backplane are supported. The KAV30
hardware provides 4 FIFOs that can be utilized by an application for
inter-processor communication using the standard KAV30 software. The
KAV30 documentation contains a pair of example programs that
demonstrate how the FIFOs on two KAV30s can be used to implement
primitive inter-processor communication.
Graham Crosbie
KAV30 Engineering
|
| 36.12 | One more time with feeling | PRIMES::FINKELSTEIN | Dept. of Redundancy Dept. | Tue Nov 05 1991 20:48 | 11 |
| Closely coupled SMP requires a shared kernel in shared memory. Loosely
coupled SMP requires that each processor have it's own copy of the
kernel but that they perform some sort of interlock instructions to the
shared memory.
Let's try this one more time. We do not need tightly coupled SMP, but
we DO need loosely coupled SMP. Let me say that again... (Nah, that
would be redundant ;-)
Harris can do it, Aeon can do it (and they make the bloody rtVAX300 for
us). Now, why can't we do it?
|
| 36.13 | tightly,closely,loosely and back again | RANGER::FALLIS | | Wed Nov 06 1991 14:21 | 27 |
| FIRST of all, I think that Closely coupled is what every one here is
looking for ? If I am wrong then maybe my note will clearify the
discussion that is going around in circles.
The present motorola VME boards and OS have Closely coupled SMP. For
those people that don't know what closely coupled is, it is multiple
kernels (CPUs) sharing memory on the VME. Loosely coupled means
communication of processors over the net, these are the definitions
that are usually used in the VAXELN documentation.
AEON, and I believe already stated the KAV30, can supply closely coupled
SMP, which means that there is a method to share memory between
processors on the VME backplane. I know for a fact that AEON can do it
and I think they have been able to share memory between the rtvax300 board and
motorola based VME boards. The last time I talked to AEON and some of
there field test sights they were testing with upto 4 to 5 VME300s and
a couple of motorola boards in a single VME backplane. When I say the
last time I mean the early days of development of the rtVAX300 and
AEON's board.(It seems so long ago !)
re.12 The rtVAX300 was designed and built by DEC, I am not sure who is
manufacturing it now, we were in the beginning, but AEON DID NOT make
the rtVAX300.
Carl
|
| 36.14 | Its possible | STAR::NORDH | VMS Development, DTN 381-1525 | Wed Nov 06 1991 14:51 | 13 |
| I can't see why WE can not do closely coupled SMP. The KAV30 can map
devices(like memory, other VME processor modules, I/O devices,
VSB memory) as the AEON module can, but using different technique.
By using the FIFO's on the KAV30 and the mapping technique, it is
possible. We must though be very careful what we are meaning when we
say SMP. Pls refer to note 36.3.
As Graham said, the KAV30 will work perfectly with multiple KAV30's and
also with other processor modules.
Jan Nordh
KAV30 (ex-)Developer
|
| 36.15 | Aeon has it now | FOOSW6::COOK | | Wed Nov 06 1991 15:35 | 13 |
|
What's really needed is a send/receive message and create_area look alike. This
should be something similar to the RTA mechanisms.
BTW, I just got a note from Aeon Systems that they now have an XMI-VME toolkit
that allows communications from VMS to the VME300.
Good thing we have third parties to put these products out.
al
|
| 36.16 | | HERR::CROSBIE | | Wed Nov 06 1991 16:22 | 16 |
| Use of the term SMP seems to be causing some confusion in this note. In
.11 I should had used the term tightly-coupled multi-processing rather
than SMP.
It IS NOT possible to implement tightly-coupled multi-processing with
the KAV30 for the reasons stated in .11.
Closely coupled multi-processing (using the definition in 36.3) IS
possible with the KAV30 from the application level using the FIFOs
and/or bus mapping routines.
It would be helpful to have some more details as to what sort of
solution the customer requires.
Graham Crosbie
KAV30 Engineering
|
| 36.17 | Easy, lets make it a DEC product and not a point product | FOOSW6::COOK | | Wed Nov 06 1991 16:51 | 15 |
|
> It would be helpful to have some more details as to what sort of
> solution the customer requires.
Howabout, I would like to see the same level of support for the KAV30 on the
VME that the KA800 has on the BI.
So, by the definitions is .3, closely coupled SMP with VAXELN system service
(or system service like) support at the VME and cross VME level.
al
|
| 36.18 | Run SMP on a REALtime machine! | LANDO::ODONNELL | | Mon Nov 11 1991 21:55 | 14 |
| re:15
I would take anything you get from AEON with a grain of salt 'till
you see something from me. I am the Product Manager for the XMI-to-VME
adapter. AEON is certainly working with us, and has been an EFT site,
but I haven't seen anything from the toolkit as yet.
The closest you're going to get to SMP, is running our XMI-to-VME
adpater on a VAX 6000 class machine that supports SMP. We allow both
CPU's and MEMORYS to be placed on the VME bus, and to interact with
the host CPU and memory as a result of mapping.
|