parsytec.uucp@rwthinf.UUCP (03/07/90)
To Transputer Mailing List:
I've been developing software for Parsytec now since nearly 4
years. Three weeks ago I read the mail from Uni Linz in Austria,
Klaus Kusche. He complained about our compatibility efforts in
such a level of detail, that I thought: "Hey, somehow he has faced
big trouble when using our systems, and our Austrian distributor
has left him alone". So I fetched the phone and told him: "I
cannot imagine your trouble, how can I help you?". I then was
simply told that he never has had or used our systems, and that he
had decided not to do so just because of those things he believed!
Surprise, I thought, funny world. But we have a lot of fun, so I
forgot it.
Now I read a similar mail from Mr. Kusche again. It says: "I just
don't like that company (Parsytec)". This really makes my blood
boil (and my management hasn't managed to calm me down): If his
hobby is transputer-system-manufacturer-bashing, why then doesn't
he switch from time to time to a new one (there are so many)?
Back to the serious world: I know a lot of the issues from the
inside. And that's what upsets me: Open systems is our major goal,
and we have paid more attention for compatibility issues and
alien-systems-support than perhaps anyone else (except the add-on
clone manufacturers). We help to support standards, both for
software (e.g. Helios) and hardware exchange (TTL-RS422, or
different bus support).
In general:
We are facing two major fractions of the transputer market:
(1) straight forward and cost-effective evaluation systems
(2) multi-user systems having complex environments and objectives.
Everyone active in (2) has to address some design decisions, which
remove them from the compatibility scope of (1).
When users are logging in and out dynamically for varying
amounts of transputers and topologies, one needs a supervisory
medium, which allows users and even single threads to negotiate
for resources, without interfering in any sense with other users
or threads.
This medium should be as transparent as possible and not at all
explicitly or implicitly limited to what fits into a box, so a
control-bus is excluded.
Furthermore any transputer structure should implicitly allow for
fault tolerance, relying on no more than the communication ways
established anyway by the links.
This all led to Parsytec's uniform link and system control
structure always and automatically having in parallel to the
transputer's data links a second communication medium serving for
partition-request/reconfiguration/reset/analyse. Because we are
active in markets (2) AND (1), we maintain this throughout the
complete product spectrum. By the way, no other vendor active in
market (2) is closer to "Inmos conventions" than us. And we
continue to follow a total "open system approach": anyone can
access any detail technical information and we are supporting as
much of the (fairly heterogeneous) outside world as possible.
Compatibility (even binary) on higher levels:
This is really a major issue. A real binary compatibility cannot
be achieved on the bare hardware level (naked transputer nodes)
if you are not willing to stay with a PC and add-in boards (e.g.
3L's TBUG heavily makes use of PC features, thus, what about the
availability for SUN users ?).
I consider a real operating system like Helios to be the only
alternative to provide compatibility on a higher level (not bare
transputers). You get a real independence from a specific host
system, and you can ignore switching topologies, reset and
booting. And commercial software houses even can distribute
binaries, which can run on varying numbers of nodes and
automatically load-balance! Finally, you've got a good deal of
unix flavour for multi transputer systems (we are running Helios
on a 128 processor SuperCluster).
Hence, the compatibility issue is solved on a system call basis
which also encourages to port UNIX software: We have ported
XWindowS based versions of CGI and GKS 2D/3D to Helios within 3
days.
As a result, we currently have a large basis of software
products from a dozen different software houses available for
Helios, just 18 month after launching version 1.0.
Reset handling:
Parsytec's reset handling (with implicit analyse) as well as
CSA's, Meiko's, Parsys', Telmat's ... is different from the
Inmos reset scheme (up/down/subsystem). Inmos did it in the very
early days for the evaluation users, and for those they did
well. As mentioned, this organisation is simply not appropriate
for real systems, specifically dynamically partitioned multiuser
systems.
Inmos compatibility:
Our systems have parsytec-to-inmos conversion facilities
integrated (e.g. SuperCluster, MultiCluster, PC-, Mac-, SUN- and
VAX-add-in boards), in addition we also have separate conversion
boxes. Furthermore the differences are only where necessary,
easy to understand, documented and not a secret at all. We
provide versions of basic system software adopted to this, even
supporting mixed parsytec/inmos networks.
We just take care about compatibility-support to Inmos, but not
to Telmat, CSA, Meiko, Parsys, Hema, Levco, Atari, ...(Sorry).
Link switching:
A C004 attached to a transputer link may cause worms to fail,
but why use a worm to find out about the topology, if you can
modify it according to your needs by programming the C004s ?????
In Parsytec's SuperClusters or MultiClusters, accessing the
C004s is hidden and done by special utilities (like Meiko's
"wire" command). Thus, even aggressive worms (e.g. in Parsec's
Par.C) cannot disturb the configuration.
Have you ever thought about how to switch up/down or subsystem
reset signals in C004 based systems ??
Link interface to bus systems:
Parsytec has link adapter interfaces to IBM-PC bus, VMEbus (e.g.
SUN), NuBus (Apple Mac), VAX Q-BUS, and IBM's Micro Channel
Architecture (e.g. MCA for PS/2). The PC interface provides a
B004 compatible register set, but we included additional
features.
Even the Logical Systems C using the DMA-driver runs without
changes. A beta version of the TDS D700E was also running
immediately.
Software interface:
We adopted the inmos linkio.c standard at the procedure level
interface and provide this interface to the user. Inside this
module, the implementation can be different, e.g. to support
protected multiuser access to a number of link adapters in a
SUN. This software interface is available for all bus
interfaces. We are also basing all software products on this
interface: Helios, TDS, toolset, LS-C, Par.C, ...
Link standards:
We have suggested to inmos to setup a conference to agree on an
international standard for link interconnections. Please send
your comments.
By the way:
What do SUN or MAC users think about the recommendation of a 386
MS-DOS machine as the only suitable way to deal with transputers ?
Friedrich Luecking
Parsytec GmbH
*******************************************************
* Friedrich Luecking *
* Parsytec GmbH *
* Juelicherstr. 388 Tel: +49 241 166000 *
* D-5100 Aachen Fax: +49 241 1660050 *
* West Germany *
* *
* UUCP: parsytec.uucp or paracom.uucp *
*******************************************************