ml@gandalf.UUCP (Marcus Leech) (05/29/89)
There has been much discussion recently of interconnect strategies for
improving overall system performance. It has been observed that many
early large-scale systems used dedicated interconnections between CPUs,
I/O controllers, and main-storage (using multi-ported memory
controllers). "Conventional" minicomputers use a "bus" design, and
improve performance by increasing the "bus" clock rate and/or widening
the data path between processors and memory.
I've often thought about what I'd do If and when I ever get around to building
my totally-awsome "personal" computer ;-). I've concluded that a compromise
between the two interconnect approaches would be both feasible and provide
not-too-shabby performance. Consider a design in which a device (CPU,
IOP, etc) can dynamically select one-of-N busses upon which to conduct
a transfer between itself and main storage. There are presumably modelling
techniques available that would tell you (for a given number of CPUs, and
I/O processors) how many busses you'd need (and the corresponding number
of ports on the multi-port memory controller) to achieve a given level
of performance. You could then pick a number of busses that satisfies an
arbitrary compromise between performance and interconnect complexity.
This approach has (IMHO) some distinct advantages:
- required bandwidth on individual bus is lower; it can be longer,
and capacitive loading is not as large a problem.
- substantial reduction in bus-contention over single-bus design.
- reduction in interconnect complexity over dedicated-interconnect
designs.
- others that I'm too dim-witted to realize ;-)
There are, of-course, design problems that would have to be resolved.
The piece of hardware that decides which bus to use would have to be
very fast, so as to not nullify the advantage of having multiple
busses. The multi-port memory controller would have to be fast enough
to service multiple requests without blocking.
This whole concept may be fundamentally flawed. After all, I'm primarily
a software person ;-) ;-).
--
"Better Living through modern chemistry" PaperMail: 130 Colonnade Rd, Nepean,ON
Marcus Leech E-mail: ml@gandalf.UUCP
Gandalf Data Ltd PacketRadio: VE3MDL@VE3JF
"The opinions expressed herein are solely my own" So there