home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / sys / transput / 1224 < prev    next >
Encoding:
Text File  |  1992-11-19  |  2.7 KB  |  57 lines
  1. Newsgroups: comp.sys.transputer
  2. Path: sparky!uunet!cs.utexas.edu!zaphod.mps.ohio-state.edu!cis.ohio-state.edu!magnus.acs.ohio-state.edu!usenet.ins.cwru.edu!agate!doc.ic.ac.uk!buck!brendan
  3. From: brendan@buck.ac.uk (Brendan Murphy)
  4. Subject: Re: Transputerlink -> Host throughput values
  5. Message-ID: <1992Nov19.201636.17506@buck.ac.uk>
  6. Organization: University of Buckingham
  7. Date: Thu, 19 Nov 92 20:16:36 GMT
  8. Lines: 42
  9.  
  10. I am posting this to the group because it might be of general interest /
  11. provoke some discussion...
  12.  
  13. In article <9211082963@gandalf.moria>, u31b3hs@pool.informatik.rwth-aachen.de 
  14. (Michael Haardt) writes:
  15.  
  16. >I would like to know some "throughput" values of the transputer-host
  17. >link.
  18. >
  19. >When I use iserver, writing 1k blocks to the host gives me a performance
  20. >of about 20k per second.  Using smaller blocks results in very reduced
  21. >performance.
  22.  
  23. What are you doing with the data on the host side - are you throwing it away
  24. or writing it to disk?  Are you using standard i/o libraries?  If so, whose
  25. libraries?
  26.  
  27. >I wrote a small program to measure only transfer speed by reading data
  28. >directly from the link.  The maximum throughput was about 110k per
  29. >second.  I think the difference results in iserver being a single
  30.                                                             ^^^^^^
  31. >threaded server, so it can't receive new packets while it processes
  32.  ^^^^^^^^
  33. >packets, which reduces performance a lot.
  34.  
  35. This is only part of the story.  A multi-threaded server per se doesn't buy
  36. you any performance improvement; your client i/o libraries and server
  37. communication protocol have to be multi-threaded too.
  38.  
  39. I have written a multi-threaded version of the iserver and I have changed the
  40. SP protocol to include a process identifier field in each packet.  A simple 
  41. asynchronous mux/demux process sits between the standard Inmos libraries and 
  42. the server; the mux/demux needs the process identifier to know to which process
  43. to return reply packets.  This environment removes the synchronous i/o 
  44. bottleneck that is a limitation of standard transputer servers; for example, 
  45. one transputer process can be doing file i/o while another is blocked doing a
  46. keyboard read.  Overall utilisation of the server is therefore improved.  Even
  47. so, one would need to write one's own multi-threaded i/o libraries in order to 
  48. reap any performance benefits at the individual file descriptor level.
  49.  
  50. Brendan
  51. -- 
  52. ********************************************************************************
  53. Brendan Murphy                    brendan%buck.ac.uk@uknet.ac.uk
  54. Department of Computer Science            Tel: 0280 814080
  55. University of Buckingham, MK18 1EG, UK        Fax: 0280 822245
  56. ********************************************************************************
  57.