Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!usc!ucsd!ucbvax!CAPSRV.JHUAPL.EDU!koontz%capvax.decnet
From: koontz%capvax.decnet@CAPSRV.JHUAPL.EDU ("CAPVAX::KOONTZ")
Newsgroups: comp.sys.transputer
Subject: RE: I/O Calls on the Transputer and General Call for Benchmarks
Message-ID: <9007271900.AA09549@tcgould.TN.CORNELL.EDU>
Date: 27 Jul 90 15:51:00 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 86

Vandana,

     You have just experienced the problem with general purpose I/O on a 
transputer.  The problem is not in the transputer itself but in the fact that it 
does not have a hard-disk attached directly to it.  Instead, it must perform 
remote procedure calls through a transputer link to a suitable interface on the 
Sun which is executing a driver to control the link adapter which must then 
respond back to a server program time-sliced with other stuff executing on the 
Sun...yuch, what a mess.

     The physical interface is one of the main bottlenecks.  On a B014, the 
VMEbus to transputer interface uses a simple Link Adapter.  The interface allows 
one byte to be transmitted or received to/from the transputer at a time.  The 
server program running in the Sun must either poll the link adapter or set up an 
interrupt.  The interrupt won't improve I/O speed since no extra buffers are 
provided; it just allows the Sun to do other things while this slow interface is 
sending or receiving a byte.

     While a transputer link can transfer around 1.75MB/sec (half-duplex @ 
20Mbps), Inmos 'sez that the B014 VMEbus interface will only handle around 
150KB/sec.  If the interface could handle the link speed, we might see up to an 
11.67 times improvement.  Thus, your T800 time could become something around 
2.7secs.  This is still 20 times slower than the Sun-3 and 40 times slower than 
the Sun-4.  So this isn't the complete answer.

     Other things probably influence the speed such as the driver for the link 
adapter and the time-slicing of other processes under Unix.  I started thinking 
maybe the speed of the SCSI disk vs. the transputer link could be a facter - but 
SCSI disks aren't that much faster (and with the seek times they are much 
slower).  You said that the benchmark doesn't actually perform any disk 
activity.  Ah...maybe that's the clue.  The times for the Sun's are so quick 
because the disk buffering is direct (and no disk activity); you're seeing the 
speed of the Sun's memory and CPU interface.  If the T800 did disk buffering in 
it's memory, you might see a time somewhere between the Sun-3 and Sun-4.  
However, the Sun is performing the disk buffering in its memory for the T800.

     So how to speed things up?  You can either get a better interface between 
the Sun and the T800 (get rid of that link adapter!) or you can connect a disk 
directly to the T800.  Or maybe you can increase the priority of the server and 
driver under Unix.  Or maybe you can get a better C compiler...

     Just for fun, I tried your benchmark on one of our PC systems.  The 
transputer hardware consists of an Inmos B008 with a B404-3 (T800-20) on Slot 0. 
The PC is a Compaq Port 386/20.  I compiled the benchmark using Logical Systems 
C v88.4.  The LSC server (cio) allows you to enable or disable the DMA 
capability on the B008.  This can speed things up a lot when using an 286-style 
PC but not as much with a 386 (the 386 can poll almost as fast as the DMA can 
transfer - it's not such a great DMA design...).  I tried it with and without 
the DMA: here's what I got:

     Trial 1: DMA disabled (polling)     3.798 sec
     Trial 2: DMA enabled                4.231 sec

Wow!  Did I misplace a decimal point?  No, I ran each 3 times and verified 
against a wall clock.  I can't believe that the B008 and B014 interfaces are 
that much different.  I suspect we're seeing the difference between a server 
running on a dedicated CPU (the PC) vs. one running under a multi-user OS like 
Unix.  Or are the drivers for the B014 to blame.

     OK netters...the source code for the benchmark is provided.  Anyone have a 
Unix system that uses a faster interface (e.g. FIFOs or dual-ported memory) from 
someone like Transtech, Meiko, Topologix, et al.  And does anyone have a T800 
with a SCSI disk connected directly and appropriate software?  Helios has a 
standalone filing system for the Inmos B422 SCSI TRAM (OUG News #13).  How about 
hereing from anyone with a Yarc transputer board or another PC-type board that 
has a faster interface to the PC.  Can our friendly neighborhood hardware 
designed at Inmos (yes Dave Boreham, that's you...) contribute any info about 
the B008 and B014 link adapter designs or the driver designs.  Do you have a 
driver for the B016 yet that uses dual-ported memory and can you run a benchmark 
on this setup?

     Sorry, I'm bored writing documentation, I like playing with benchmarks, and 
this looks like an interesting one for figuring out filer performance.  This 
looks like a fun project to get lots of times from different HW/SW 
configurations.  It'll take each person about 15 minutes to get it from your 
email file into your system, compile it, and read the numbers.  I'll try to keep 
track of the scores.

     So let's all go play in our sandboxes and compare results.


Ken Koontz
The Johns Hopkins University
  Applied Physics Laboratory
Laurel, MD USA 
email: koontz@capsrv.jhuapl.edu