Thread View: comp.sys.transputer
1 messages
1 total messages
Started by Brendan Murphy
Thu, 19 Nov 1992 20:16
Re: Transputerlink -> Host throughput values
Author: Brendan Murphy
Date: Thu, 19 Nov 1992 20:16
Date: Thu, 19 Nov 1992 20:16
47 lines
2784 bytes
2784 bytes
I am posting this to the group because it might be of general interest /
provoke some discussion...
In article <9211082963@gandalf.moria>, u31b3hs@pool.informatik.rwth-aachen.de
(Michael Haardt) writes:
>I would like to know some "throughput" values of the transputer-host
>link.
>
>When I use iserver, writing 1k blocks to the host gives me a performance
>of about 20k per second. Using smaller blocks results in very reduced
>performance.
What are you doing with the data on the host side - are you throwing it away
or writing it to disk? Are you using standard i/o libraries? If so, whose
libraries?
>I wrote a small program to measure only transfer speed by reading data
>directly from the link. The maximum throughput was about 110k per
>second. I think the difference results in iserver being a single
^^^^^^
>threaded server, so it can't receive new packets while it processes
^^^^^^^^
>packets, which reduces performance a lot.
This is only part of the story. A multi-threaded server per se doesn't buy
you any performance improvement; your client i/o libraries and server
communication protocol have to be multi-threaded too.
I have written a multi-threaded version of the iserver and I have changed the
SP protocol to include a process identifier field in each packet. A simple
asynchronous mux/demux process sits between the standard Inmos libraries and
the server; the mux/demux needs the process identifier to know to which process
to return reply packets. This environment removes the synchronous i/o
bottleneck that is a limitation of standard transputer servers; for example,
one transputer process can be doing file i/o while another is blocked doing a
keyboard read. Overall utilisation of the server is therefore improved. Even
so, one would need to write one's own multi-threaded i/o libraries in order to
reap any performance benefits at the individual file descriptor level.
Brendan
--
********************************************************************************
Brendan Murphy brendan%buck.ac.uk@uknet.ac.uk
Department of Computer Science Tel: 0280 814080
University of Buckingham, MK18 1EG, UK Fax: 0280 822245
********************************************************************************
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