🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

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
#1729
Author: Brendan Murphy
Date: Thu, 19 Nov 1992 20:16
47 lines
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