Thread View: comp.sys.transputer
2 messages
2 total messages
Started by Marco Kesseler
Thu, 08 Oct 1992 13:35
Request (T800) Router Information
Author: Marco Kesseler
Date: Thu, 08 Oct 1992 13:35
Date: Thu, 08 Oct 1992 13:35
55 lines
2468 bytes
2468 bytes
Dear everybody, I know a lot of people have been working on routers for the transputer. So did I some time ago. I'm wondering what the current situation is in this field (apologies if all this sounds too familiar). Please don't send me messages like 'I'm using product 'x' and it is really good'. I'm even less interested in a discussion about the merits of different solutions. I just want to get a survey of what's available. To be more specific: I'm looking for concrete and up-to-date (references to) information about existing, reliable routing software for the transputer (T800 and down). It should be deadlock-free and preferably starvation-free as well. Things that interest me are: - method/algorithm/protocol used. In what way is deadlock prevented? Timeouts? Classes? Specific safe topologies? etc. - results (bytes/sec/link, delay, memory requirements etc.) for different message size, different loads, different topologies etc. I prefer results for large networks, high load and extremely small/large messages. - interface: does it provide 'channels' between processes, some block move between processors or something else? Are messages buffered at the destination? synchronous or asynchronous communication? - availability (which language/architecure). Is source code available? - for which applications has it been used? I've implemented a packet router myself that uses a class climbing algorithm to prevent deadlocks (provided every packet is consumed at the destination within a finite amount of time). It is starvation-free and uses an adaptive routing strategy (using shortest paths). It has been used for a prototype transputer implementation of the (lazy) functional language Concurrent Clean. I'd like to compare my router to other routers anybody is willing to tell me about. Please feel free to use my e-mail address (marcok@cs.kun.nl) to respond. Thanks! Marco Kesseler Faculty of Mathematics and Computer Science University of Nijmegen Toernooiveld 1 6525 ED Nijmegen The Netherlands marcok@cs.kun.nl
Re: Request (T800) Router Information
Author: Mark Debbage
Date: Tue, 13 Oct 1992 15:38
Date: Tue, 13 Oct 1992 15:38
132 lines
6523 bytes
6523 bytes
In article <Bvt1qK.Loy@sci.kun.nl>, marcok@cs.kun.nl (Marco Kesseler) writes:
|> Dear everybody,
|>
|> I know a lot of people have been working on routers for the
|> transputer. So did I some time ago. I'm wondering what the current
|> situation
|> is in this field (apologies if all this sounds too familiar).
|>
|> Please feel free to use my e-mail address (marcok@cs.kun.nl) to respond.
|>
Sorry to waste net bandwidth with this but this e-mail address just bounces
for me. Information regarding the Virtual Channel Router and its Universal
Packet Router component follow. These systems were developed at the University
of Southampton with compiler support from Inmos.
Mark Debbage, md@uk.ac.soton.ecs
-----------------------------------------------------------------------------
The Universal Packet Router (UPR) is a general-purpose router for arbitrary
routers. It has been specifically designed so as to permit communication
protocols to be implemented without unnecessary regard to machine topology.
The UPR has been used to implement a range of environments:
* The Virtual Channel Router (VCR) supports distributed occam programs without
any language changes, and C and FORTRAN through a library interface. A
configuration language is used to describe a static interconnection of
point-to-point channels. These are synchronous (unbuffered) and pass
arbitrary-length messages. There is also the ability to select (alternate)
over a list input-channel ends. VCR also has dynamic extensions including
RPC and dynamic virtual channels allowing distributed parallelism to be
invoked on the fly.
* PARMACS is a message-passing library for FORTRAN and C using synchronous
and asynchronous blocking calls. It has direct support for tree-based
operations (reduction, broadcasting) and a barrier call. It is particularly
good for data-parallel applications since it knows how to map algorithm
graphs onto processor topologies. It can also generate trace-files.
* PICL is another message-passing library for C with similar, though more
expansive, features to PARMACS.
* IDRIS is a distributed POSIX-conformant UNIX for transputers sold as a
commercial product by Parsys for their Supernode architectures.
* The most recent 3L C System uses UPR for its virtual communications
facilities. This also runs on TMS320C40 using the UPR kernel.
* A port of CHIMP, Common High-level Interface for Message-Passing, to
transputers using UPR is underway at the University of Edinburgh.
* VPI, virtual processor interface, is an environment to support the rapid
prototyping of new environments.
* UBIK, an environment exploiting distributed shared memory techniques.
UPR itself features a well-defined interface (UPRI) allowing arbitrary protocols
to be fashioned on its primitives. The interface specifies a reliable
asynchronous packet delivery service which can move packets from a sourcing
processor to a particular port number on a destination number. Outputting of
packets is by enqueuing operations while the receiving of packets is obtained
by binding protocol-specific function calls to particular port numbers. The
UPR interface requires that protocols are eager readers.
UPR is guaranteed deadlock-free on arbitrary topologies. This is accomplished
automatically using structured buffer pools and virtual links techniques for
general networks. Special cases, such as grids, are recognised and deadlock-free
routed using optimal methods. The router uses exclusively shortest-path routes;
these are calculated statically off-line using a network configuration tool.
There is no route adaption; each processor has a table indicating which one
link to use to get to any other processor.
The design of UPR is for maximum performance exploiting full use of transputer
architecture: internal memory, parallel link activity, fast context switch.
The code is all in C with some assembler mechanisms accessed through macro
expansion. We choose to use 160 byte packets but this is just a compile-time
constant.
In terms of performance I give the following figures for the router running
on T800 processors at 25MHz with 20 MBit links and 4-cycle DRAM. The router
was used in a high performance mode (security checking turned off) and for
a deadlock free network. 8 packet buffers were associated with each link.
Processing consumption for a packet through route:
33 us for 0 byte packet, 44 us for 160 byte packet
Node bandwidth (data that can be routed through a processor) :
Linear with packet size from
0 byte packet, 0 bandwidth :-( to
120 byte packet, 6.6 MByte ;-)
Grows slowly after this:
160 byte packet, 6.7 MByte
500 byte packet, 8.4 MByte
Link-to-link throughput:
We get 1.24 MByte out of a single link with 160 byte packets
We get 1.48 MByte out of a single link with 500 byte packets
Applications
------------
Using occam interface many including:
CFD
QCD
Distributed shared memory simulations
Local Particle-Mesh Device Simulation
PARMACS:
All of the message-passing kernels from the above
Plus multigrid codes.
Lots of others using the other top-levels that I don't know about.
VCR is distributed freely with source and includes UPR. We are considering
the best way to distribute the PARMACS top-level. We hope to be set up for
anonymous FTP soon
Hope this information is of interest. If you want more detail we have papers
on UPR, UPRI and VCR.
Regards,
Mark.
+-----------------------------------------+---------------------------+
| Mr. Mark Debbage, Research Assistant | email: md@uk.ac.soton.ecs |
| Room 324 Mountbatten Building | tel: (0703) 592897 |
| Dept. of Electronics & Computer Science | fax: (0703) 593045 |
| University of Southampton | |
| Highfield, Southampton SO9 5NH | |
+-----------------------------------------+---------------------------+
Thread Navigation
This is a paginated view of messages in the thread with full content displayed inline.
Messages are displayed in chronological order, with the original post highlighted in green.
Use pagination controls to navigate through all messages in large threads.
Back to All Threads