🚀 go-pugleaf

Here at the University of Manchester, England, we have been using dynamically
reconfigured transputer links for some time now. We have a home-built 64
transputer machine, known as the T-Rack. Two links from each transputer
connect up to a large 128 x 128 C004 crossbar network (the extra large size is
to allow external connections). The C004s are controlled by a separate switch
control transputer.

An 8-bit bus allows bidirectional communication between the 64 application
transputers and the switch control transputer. Application transputers can
ask (via the bus) for link connections to be set up or relinquished at run
time. The switch controller installs the required links, and sends back an
acknowledgement to the requesting transputer(s). The T-Rack was not designed
with dynamic reconfiguration in mind, so "link throughput" performance is not
as good as it could be.

Early work [1, 2, 3] featured a sender-node request protocol, in which the
message sending transputer would be responsible for the request / release of
switched link connections. This protocol has the disadvantage that receiver
nodes must be organised so as to have a message receiver process active at all
times, to accept any incoming messages arriving from remote senders.

In occam, the ownership of a communication channel is shared by the processes
it connects. Synchronous channel communication requires that both the message
sender and receiver must be ready to communicate before any data is sent down
the channel.

A dynamic link reconfiguration protocol should reflect this - both the
sending node and the receiving node should agree that they require a link over
which to communicate. More recent work here at Manchester [4] has featured a
new sender-receiver-node link request protocol, in which both transputers must
register their interest in using a dynamic link.

The use of this second request protocol has allowed the development of
elegantly coded distributed applications, free from the clutter of message
forwarding / channel multiplexing processes, and with fully synchronous
point-to-point communications between any pair of processes anywhere in the
network. Parallel efficiency is low when the levels of communication
are much higher than the levels of computation. Increasing the compute to
communicate ratio can alleviate the link request overheads, however.

References:
-----------
  [1]	P.Jones, A. Murta, "Support for Occam Channels via Dynamic Switching
	in Multi-Transputer Machines", OUG 9 Proceedings, 1988, IOS Amsterdam.
  [2]	P.Jones, A. Murta, "Practical Experience of Run-Time Link
	Reconfiguration in a Multi-Transputer Machine", Concurrency: Practice
	and Experience, 1, 2, December 1989, John Wiley.
  [3]	P. Jones, A. Murta, "The Implementation of a Run-Time Link Switching
	Environment for Multi-Transputer Machines", NATUG 2 Proceedings, 1989.
  [4]	A. Murta, "Support for Transputer Based Program Development via
	Run-Time Link Reconfiguration", Ph.D. Thesis, University of
	Manchester, (under preparation - due late 1991).

---------------------------------------------------------------------------
Alan Murta   Department of Computer Science, University of Manchester,
Lecturer     Oxford Road, Manchester, M13 9PL, U.K.  Tel: (+44) 61-275-6259
             Mail: adm@uk.ac.man.cs     adm%cs.man.ac.uk@nsfnet-relay.ac.uk
---------------------------------------------------------------------------

We have a 16 transputer system and one C004 link switch. As the C004 has
only 32 in/outputs, the other 32 links must be put into a fixed
configuration. Any suggestion about what would be a good one? We want to be
able to make the usual networks: grid, ring, torus, tree, 4d cube etc.
Anyway much less than 32! different ones. 

We don't find it very useful to have more than one connection between two
transputers, or to connect a transputer to itself. The numbering of the
links is also not important. And all connections just bidirectional.
-- 
Piet* van Oostrum, Dept of Computer Science, Utrecht University,
Padualaan 14, P.O. Box 80.089, 3508 TB Utrecht, The Netherlands.
Telephone: +31 30 531806   Uucp:   uunet!mcsun!ruuinf!piet
Telefax:   +31 30 513791   Internet:  piet@cs.ruu.nl   (*`Pete')