home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / sys / transput / 1219 < prev    next >
Encoding:
Text File  |  1992-11-19  |  3.1 KB  |  70 lines
  1. Newsgroups: comp.sys.transputer
  2. Path: sparky!uunet!mcsun!Germany.EU.net!Urmel.Informatik.RWTH-Aachen.DE!gandalf!michael
  3. From: michael@gandalf.moria (Michael Haardt)
  4. Subject: Summary: Transputerlink -> Host throughput values
  5. Message-ID: <921118978@gandalf.moria>
  6. Lines: 68
  7. Sender: news@Urmel.Informatik.RWTH-Aachen.DE (Newsfiles Owner)
  8. Nntp-Posting-Host: rama
  9. Reply-To: u31b3hs@pool.informatik.rwth-aachen.de (Michael Haardt)
  10. Organization: An old and gray machine, somewhere in Moria.
  11. Date: Wed, 18 Nov 92 14:45:01 +0100
  12. Return-Path: <u31b3hs@pool.informatik.rwth-aachen.de>
  13. Lines: 55
  14.  
  15. My original article:
  16.  
  17. |> I would like to know some "throughput" values of the transputer-host
  18. |> link.
  19. |> 
  20. |> When I use iserver, writing 1k blocks to the host gives me a performance
  21. |> of about 20k per second.  Using smaller blocks results in very reduced
  22. |> performance.
  23. |> 
  24. |> I wrote a small program to measure only transfer speed by reading data
  25. |> directly from the link.  The maximum throughput was about 110k per
  26. |> second.  I think the difference results in iserver being a single
  27. |> threaded server, so it can't receive new packets while it processes
  28. |> packets, which reduces performance a lot.
  29.  
  30. My machine is a 386-20 without cache, I use a B004 compatible board without
  31. interrrupts.  The machine has about 4500 dhrystones.
  32.  
  33. From: Bob Green <bob@inmos.co.uk>
  34.  
  35. > Even if iserver were multi-threaded, that wouldn't help, since when the iserver
  36. > protocol was invented, it was specified as being synchronous. i.e. an application
  37. > won't even attempt to submit a second request until a reply to its first request
  38. > has been received.
  39.  
  40. True, a asynchronous protocol would be needed for a multi-threaded
  41. server.  Of course that requires more complicated software at the
  42. transputer side, too.
  43.  
  44. From: Charles Francois  <Charles.Francois@sophia.inria.fr>
  45.  
  46. > ...                         We had 6 transputers for that purpose,
  47. > that were bound to a Sun3/140 via VME 8/32 (B014 from INMOS). Is it
  48. > the one that you are using?  I modified the iserver from INMOS to
  49. > make it work over the Ethernet, so that the transputer network
  50. > would be accessible from a Sparcstation for example.  There was no
  51. > other procress running on the Sun3/140, apart from the usual
  52. > deamons.  Well, the best I could get was about 40Kbytes/sec.
  53. > ...                              I think that there is no miracle
  54. > to be expected from this board, and I was told that it is a general
  55. > complaint.  For fast transfer, maybe you should consider the B016
  56. > (which as 4M of shared memory) or the B300 (direct interface to
  57. > Ethernet).
  58.  
  59. As it seems, iserver isn't best choice if you have to transfer big
  60. amounts of data between host and transputer.  The only easy tuning which
  61. could be done is modifing the iserver protocol to allow bigger packets,
  62. because my benchmarks showed that there were huge differences between
  63. e.g. 512 and 1024 user data packets.  Of course that doesn't help if
  64. the problem forbids blocking.
  65.  
  66. For high performance, either i/o devices should be directly connected to
  67. a transputerlink or you use at least your own problem specific protocol.
  68.  
  69. Michael
  70.