Category Archives: Using Transputers

The Inmos C004

May 21, 2015 Axel Leave a comment

Hardware

Before I reinvent the wheel, here’s the quick intro from the manual, what an Inmos C004 actually is:

The IMS C004 is a transparent programmable link switch designed to provide a full crossbar switch between 32 link inputs and 32 link outputs. The IMS C004 will switch links running at either the standard speed of 10 Mbits/sec or at the higher speed of 20 Mbits/sec.
It introduces, on average, only a 1.75 bit time delay on the signal. Link switches can be cascaded to any depth without loss of signal integrity and can be used to construct reconfigurable networks of arbitrary size. The switch is programmed via a separate serial link called the configuration link.

So in simple words: 32 inputs can be freely connected to 32 outputs. Great for large Transputer networks which can be reconfigured only by reprogramming the C004 – on top of that, you can cascade them and create huge, complex networks to make any connection imaginable possible. Like those Parsytec used in their SuperCluster machines looking like this:

Yes, that’s 13 C004s and one Transputer to rule them all…

… so much for the theory.

In practice, the C004 is a bitch. Not only does it require a Transputer to configure it (normally a 16bit T2xx) it also adds quite a delay into the link-communication. As mentioned above, it’s “only a 1.75 bit time delay” but this can sum up to quite an amount.
Let me quote some more realistic numbers from the Helios manual (pp.255):

It is of interest to ascertain the effect of the Inmos C004 on the performance of the Helios communication mechanisms. Figure 6.3 illustrates the rates of data communication (Kbytes/second) attained using message passing primitives (PutMsg() and GetMsg()) between two Transputers that were
1. Directly linked and
2. Connected through a C004 link switch.
It is evident from Figure 6.3 that the effect of the C004 link switch on the rate of communication is far from negligible. The overhead imposed by the link switch increases with the size of the message. In the worst case (64 Kbyte message), transmission through the C004 is 23 % slower than sending data over directly connected links.

Oops. 23% is quite essential. So before planning to set up a crazy C004 network you might consider what you want to achieve.
Is it for educational network studies only? Fine.
Are you going for speed and rarely change your Transputer network configuration? Avoid it!

IMHO even the 10 possible Transputers on an IMSB008 do not require a C004 making your day.
Actually, even Parsytec thought that this is useless to use a link switch for the 16 Transputers in their beautiful x’plorer and replaced it by hard-wire dummies:

Configuration

Ok, you’re still not scared away and really do like to know how to handle that beast. Fine, here’s what I went through:

To work with a C004 you obviously need either a TRAM carrier like the B008 or some sort of motherboard like the IMSB012 or IMSB014. Read the boards manual to understand how to connect to the T2xx Network Control Processor (NCP).
For example the IMSB012 has extra pins for “config down” (i.e. IN) and “config up” (i.e. OUT) for its T212 and any other boards being chained to it.
As for the IMSB008 has its T222 connected to Link 1 of TRAM 0.

The hardware wiring is important to know, because this information is needed for the so-called hardwire file used by the INMOS tool “MMS2” (Module Motherboard Software, MSDOS only, the manual is available here).
After reading the manual (do!) you should be able to read this hardwire file for an B008 quite easily. It describes the complete hardware setup and all physical connection between the C004(s), T2xx and Transputer/TRAM links on the board:

-- B008 hardwire description
DEF B008
  SIZES
    T2 1
    C4 1
    SLOT 10
    EDGE 10
   END
   T2CHAIN
     T2 0, LINK 3 C4 0
   END
   HARDWIRE
     SLOT 0,LINK 2 TO SLOT 1,LINK 1
     SLOT 1,LINK 2 TO SLOT 2,LINK 1
     SLOT 2,LINK 2 TO SLOT 3,LINK 1
     SLOT 3,LINK 2 TO SLOT 4,LINK 1
     SLOT 4,LINK 2 TO SLOT 5,LINK 1
     SLOT 5,LINK 2 TO SLOT 6,LINK 1
     SLOT 6,LINK 2 TO SLOT 7,LINK 1
     SLOT 7,LINK 2 TO SLOT 8,LINK 1
     SLOT 8,LINK 2 TO SLOT 9,LINK 1
     C4 0,LINK 10 TO SLOT 0,LINK 3
     C4 0,LINK 1 TO SLOT 1,LINK 0
     C4 0,LINK 11 TO SLOT 1,LINK 3
     C4 0,LINK 2 TO SLOT 2,LINK 0
     C4 0,LINK 12 TO SLOT 2,LINK 3
     C4 0,LINK 3 TO SLOT 3,LINK 0
     C4 0,LINK 13 TO SLOT 3,LINK 3
     C4 0,LINK 4 TO SLOT 4,LINK 0
     C4 0,LINK 14 TO SLOT 4,LINK 3
     C4 0,LINK 5 TO SLOT 5,LINK 0
     C4 0,LINK 15 TO SLOT 5,LINK 3
     C4 0,LINK 6 TO SLOT 6,LINK 0
     C4 0,LINK 16 TO SLOT 6,LINK 3
     C4 0,LINK 7 TO SLOT 7,LINK 0
     C4 0,LINK 17 TO SLOT 7,LINK 3
     C4 0,LINK 8 TO SLOT 8,LINK 0
     C4 0,LINK 18 TO SLOT 8,LINK 3
     C4 0,LINK 9 TO SLOT 9,LINK 0
     C4 0,LINK 19 TO SLOT 9,LINK 3
     C4 0,LINK 20 TO EDGE 0
     C4 0,LINK 21 TO EDGE 1
     C4 0,LINK 22 TO EDGE 2
     C4 0,LINK 23 TO EDGE 3
     C4 0,LINK 24 TO EDGE 4
     C4 0,LINK 25 TO EDGE 5
     C4 0,LINK 26 TO EDGE 6
     C4 0,LINK 27 TO EDGE 7
 -- Uncomment the next two lines if the
 -- patch header wiring is used to
 -- connect C004, link 28 to PatchLink0,
 -- and C004, link 29 to PatchLink1.
 -- C4 0,LINK 28 TO EDGE 8
 -- C4 0,LINK 29 TO EDGE 9
   END
PIPE B008 END

After that’s done, you can prepare a second file. The so called “softwire file” which actually tells the T2xx how to internally connect his in- and out-links. A very simple example would be:

SOFTWIRE 
PIPE 0
 SLOT 0,3 TO SLOT 1,3 
END

This would connect TRAM-0’s 3rd link to TRAM-1’s 3rd link.
Now that you have the necessary config files let’s move on to the MMS itself.

Software

As with nearly every software from INMOS the MMS too is written in OCCAM and therefore has to run on a Transputer. This might be the one in TRAM slot 0 on your B008 or on a local ISA board which itself is connected with 2 links to a B012 (one for config and one to the Transputer network).

To make things easier, I prepared a complete MMS archive to download here (links to my Transputer Software page).
It contains some example soft- and hardwire files, an ISERVER.EXE (the program you need to upload code into your Transputer) as well as a batch file to easily start MMS (RUN_MMS.BAT).
Also you will find a folder with INMOS’ pimped version of ANSI.SYS called BANSI (“Better ANSI”), because all INMOS tools make heavy use of ANSI screen control. So put that into your CONFIG.SYS.

Before we begin, let’s have a look at my IMSB012 with ispy:

ispy 2.33
   # Part rate Mb Bt [  Link0  Link1  Link2  Link3 ]
   0 T800d-25 0.37 0 [   HOST    1:1    2:1    ... ]
   1 T2   -20 1.64 1 [    ...    0:1    ...    ... ]
   2 T800d-25 1.75 1 [    ...    0:2    3:1    ... ]
   3 T800d-25 1.77 1 [    ...    2:2    4:1    ... ]
   4 T800d-25 1.77 1 [    ...    3:2    5:1    ... ]
   5 T800d-25 1.75 1 [    ...    4:2    6:1    ... ]
   6 T800d-25 1.75 1 [    ...    5:2    7:1    ... ]
   7 T800d-25 1.75 1 [    ...    6:2    8:1    ... ]
   8 T800d-25 1.75 1 [    ...    7:2    9:1    ... ]
   9 T800d-25 1.75 1 [    ...    8:2   10:1    ... ]
  10 T800d-25 1.75 1 [    ...    9:2   11:1    ... ]
  11 T800d-25 1.75 1 [    ...   10:2   12:1    ... ]
  12 T800d-25 1.75 1 [    ...   11:2   13:1    ... ]
  13 T800d-25 1.77 1 [    ...   12:2   14:1    ... ]
  14 T800d-25 1.77 1 [    ...   13:2   15:1    ... ]
  15 T800d-25 1.75 1 [    ...   14:2   16:1    ... ]
  16 T800d-25 1.77 1 [    ...   15:2   17:1    ... ]
  17 T800d-25 1.77 1 [    ...   16:2    ...    ... ]

Ok, let’s start MMS2. Use/modify the batch “run_mms.bat” which will do all environment variables expected by iserver.exe and also adds the input and output files – change it as you please.
If everything works fine, iserver loads MMS2.B4 onto your Transputer and executes it. Your screen should look like the screenshot below.
First, I suggest you press “c” for checking the consistency of your hard/softwire files – if everything’s fine, MMS2 will print “Source files checked O.K.” as seen in the lowest line in the screenshot.

Just for the fun of it, you can try MMS’ very own network worm – so press “n” to start the network mapper. You will see that it is much slower than e.g. ispy, so just be patient.
After some seconds, you should get something like this:

Now it’s time to program you network. So press “s” to set the C004(s). Some infos will rush trough the bottom line of the screen and finally MMS2 states “C004 setting preformed O.K.“:

Nothing more to do here so press “q” to quit MMS2. (Do not run the network mapper again! It seems to reset the T2 and in my case reproducibly crashes the network).
It’s better to use ispy. ispy v2.33 to be precise. I encountered several issues with the C004 and the most recent version 3.23 of ispy.

So running ispy including the /C4 switch to display the settings of the two C004s now shows this – mind all the new connections of each Transputers Link0 and 3:

ispy 2.33
   # Part rate Mb Bt [  Link0  Link1  Link2  Link3 ]
   0 T800d-25 0.37 0 [   HOST    1:1    4:1    ... ]
   1 T2   -20 1.74 1 [    2:C    0:1    ...    3:C ]
   2 C004b   [ 6S3JM54V --U8-1C- -G--F9-I T--7-PQ- ]
   3 C004b   [ -D-2650R BL--E--K H-N3--4- -TU-1OA7 ]
   4 T800d-25 1.65 1 [    ...    0:2    5:1    6:0 ]
   5 T800d-25 1.75 1 [    ...    4:2    7:1    8:0 ]
   6 T800d-25 1.41 0 [    4:3    9:2    8:1   10:0 ]
   7 T800d-25 1.75 1 [    ...    5:2    9:1   11:0 ]
   8 T800d-25 1.41 0 [    5:3    6:2   11:1   12:0 ]
   9 T800d-25 1.75 2 [    ...    7:2    6:1   13:0 ]
  10 T800d-25 1.35 0 [    6:3   13:2   12:1   14:0 ]
  11 T800d-25 1.41 0 [    7:3    8:2   13:1   15:0 ]
  12 T800d-25 1.42 0 [    8:3   10:2   15:1   16:0 ]
  13 T800d-25 1.32 0 [    9:3   11:2   10:1   17:0 ]
  14 T800d-25 1.35 0 [   10:3   17:2   16:1    ... ]
  15 T800d-25 1.41 0 [   11:3   12:2   17:1   18:0 ]
  16 T800d-25 1.33 0 [   12:3   14:2   18:1    ... ]
  17 T800d-25 1.32 0 [   13:3   15:2   14:1   19:0 ]
  18 T800d-25 1.35 0 [   15:3   16:2   19:1    ... ]
  19 T800d-25 1.32 0 [   17:3   18:2    ...    ... ]

Yay! It worked. Positively as well as negatively.
Besides the new connections you might also spot a difference in the link-speed column. In our first run of ispy all Transputers had a link-speed around 1.75MBps. Now it varies between 1.75 and 1.32, depending on how often the ispy worm crossed a C004.

Two final hints:

If your C004 network has been set-up as planned, you can use ispys output to programm the network later.
Just save the output into an ASCII file (ispy /c4 > my_net.txt) and when needed feed it back into ispy like this:
ispy /r /cr < my_net.txt
This will reset the network and read in the configuration from stdin.
Obviously you can also manually edit the text file, the c4 lines

   2 C004b   [ 6S3JM54V --U8-1C- -G--F9-I T--7-PQ- ]
   3 C004b   [ -D-2650R BL--E--K H-N3--4- -TU-1OA7 ]

which isn’t as comfortable and comprehensible as editing a hard/softwire file. But your mileage my vary.

Alternatively, MMS2 can create a bootable file with your network settings. This can be used for quickly setting-up your system.
Just hit the “b” key and enter a filename. My MMS2 archive contains the above example as “BOOTB012.BTL”. Run it with “iserver /SB bootb012.btl“.

Caveats

Mind your reset! This means, in many cases a root Transputer might reset all the “worker Transputers” but also your T2xx and in effect all C004. So be careful when resetting your system.

Yes, theoretically you can reconfigure your Inmos C004 on the fly while all connected Transputer run. The most prominent example is having one network topology during data acquisition while changing it for number crunching later on.
This requires a very good knowledge of the notwork and thorough process locking etc.

Using Transputers

Basic Transputer Tools

June 1, 2015 Axel Leave a comment

Ok, so you have your shiny (not so) new Transputer system installed/connected and you really like to know if it works and at least see some results… you’re in need of basic Transputer tools to get started.

First, download the Geekdot “Transputer Tool Kit” from my Transputer software page (New releases are possible, mind the version number).
Each tool introduced here has its own folder in the archive.

ispy/mtest

Even it’s historically not the first application ever developed for Transputers it’s for sure one of the most used.
It started as ‘check‘ and at some point got renamed into ‘ispy‘ – whatever the name is, the technical term would be “network worm”. This means it’s a special piece of code which a) sniffs around in a transputer (what kind, number of links and their speed) and b) replicates itself over all links it previously found.
When done, it outputs a network map like this example:

Using 150 ispy 3.23
 # Part rate Link# [ Link0 Link1 Link2 Link3 ] by Andy!
 0 T800d-25 292k 0 [ HOST   ...   ...   1:0  ]
 1 T425c-20 1.6M 0 [  0:3   2:0   3:0   ...  ]
 2 T400c-20 1.8M 0 [  1:1   ...   ...   ...  ]
 3 T400c-20 1.7M 0 [  1:2   ...   ...   ...  ]

ispy is used on geekdot.com extensively, so any time I write about Transputers you will see some sort of ispy output for sure.
There are several versions of ispy included in this kit. This is because some versions behave more stable than other in certain circumstances. E.g. the most recent version 3.23 does not work very well with the C004 link-switches.

“The other part” of ispy is called mtest. mtest takes ispys output and runs an indepth memory test/report on all Transputers found.

iserver

iserver is part of what INMOS called “itools” – long before Apple discovered the “i” for themselves 😉 – there were many others, mainly development focused (e.g. idebug, icconf etc.).
It is more or less the successor to the godfather of all Transputer booting tools “afserver” (1988). Well, it has to be, being the on INMOS supplied with all their other tools and languages.
The possible options are quite self-explanatory and printed to stdout when omitting any option:

Basically if you see a *.btl, *.b4 or *.b8 file it’s most likely meant to be executed with iserver. Before running successfully iserver need some environment variables set to successfully to be used:

set IBOARDSIZE=#100000
set TRANSPUTER=#150

These two settings tell all itools how much RAM the Transputer has to work with and at which port address it can be found (0x150 is default anyway). The archive contains V1.42h from Nov. 1990 which is the most recent as far as I know.

Mandelbrot

The “CSA Mandelzoom Version” is one of my favorite benchmark tools. I like it so much, that I run it once a while just for fun.. and to extend my benchmark table which I’ve collected over the time using it.

It is nice because it features integer (T4xx) as well as floating point (T8xx) versions of the calculation ‘slave processes’ and scans the network itself. No external tool needed. It’s also possible to let the host (i.e. your PC) calculate the Mandelbrot fractal to get an idea, how much faster/slower your Transputer network is – the archive contains a little benchmark result text file which I accumulated over the years.
Also there are some handy switches available (‘-h’ for help):

-v : Use VGA graphics
-t : Run on host instead of Transputers
-a : Autozoom, loads a list of coordinates from man.dat and start calculating them without manual interaction.
-b : Use a different base address (instead 0x150)
-x : Verbose output of the Transputer initialization process (added by me)

After a while I got tired of manually time a calculation run and also ran into problems with large networks which simply became to fast to hand time. So I extended the code of Mandelzoom with a high precision timer (TCHRT, shareware, can’t remove the splashscreen, sorry) which prints out a timer summary when run with the “-a” parameter. I provided my default “MAN.DAT” file, which contains 2 coordinates to calculate (1st & 2nd run) and used for all my benchmarks.

These are the results of my DOS host system running in VirtualBox.

Caveat: It breaks if there’s a T2xx in the network (e.g. B008/B012) 🙁 And as always: Read the F-ing README.txt!

Since I started to heavily modifying the source, I wrote a post of its own about it as well as put everything on github, so you can join the fun 😉

Other Tools

iskip

iskip can be very handy, when ‘talking’ directly to (externally) connected links, e.g. another network which is connected to your root Transputer. Here’s a good example:
You like to put code directly onto “processor 1” which is connected to link 2 of your root Transputer:

So you call

iskip 2 /r /e

This sets up the system to direct the program to the target network over the top of the root transputer and starts the route-through process on the root transputer. Options ‘R’ and ‘E’ respectively reset the target network and direct the host file server to monitor the halt-on-errorflag. The program can then be loaded ‘through’ the root Transputer directly onto processor 1 using:

iserver /ss /se /sc test.btl

debug.exe

Yes, I do mean the comes-with-DOS debug.exe. Well, you can use any debugger you like as long it can read/write to port addresses.
Obviously this means [MS|PC|Open|Free]DOS only. You won’t get far with this on Linux, any Windows or OS/2. At least for initial debugging and testing I strongly recommend to use the “bloated interrupt manager” known as DOS.
First of all, you have to know the port addresses the C012 registers are mapped to . There’s a de-facto industry standard which INMOS introduced with the IMSB004. Its been adopted by 90% of all 3rd party products, even with certain ISDN cards using Transputes.

The base address normally is at 0x150 (which can be configured to other addresses in some cases). From this base adress the offset is always the same:

Base Adress	Register	Comment
+0x00	C012 input data	read
+0x01	C012 Output data	write
+0x02	C012 input status register	read = returns input status write = set input interrupt on/off
+0x03	C012 Output status register	read = returns output status write = set output interrupt on/off
+0x10	Reset/Error register	write: Reset Transputer & C012 and possibly subsystem (check manual) read: Get Error status
+0x11	Analyse register	(un)set analyse

So here’s a clean Transputer setup ‘conversation’ using debug (comments are just for clarity, not supported in debug):

c:\>debug
 -o 160 1         # Assert RESET
 -o 161 0         # Deassert ANALYSE
 -o 160 0         # Deassert RESET ... init B004/IMSC
 -o 152 0         # Clear Input  Interrupt enable
 -o 153 0         # Clear Output Interrupt enable
 -i 152           # Read Input Status
 00               # Bit 0 = 0 -> no Data waiting
 -i 153           # Read Output Status
 01               # Bit 0 = 1 -> ready to send 
 -i 160           # Read Error
 00               # Bit 0 = 0 -> ERROR not signaled
-o 151 1          # send POKE
-i 153            # Read Output Status
01                # Ready -> POKE Ack (00 = BAD no Transputer)

After that you’re fine to send and receive bytes through 0x151/0x150. Doing so, you’re completely free which programming language to use. Here are some examples in AppleSoft Basic or even Python.

Using Transputers

IMSB012 C004 replacement

July 14, 2015 Axel Leave a comment

The IMSB012 is my favorite TRAM carrier board. Room for max. 16 (size-1) TRAMs and plenty of external connectors. The perfect platform to build a successor of the ‘Tower of Power’.

Like with all TRAM carriers having more than 8 slots, it was a good decision to put at least one C004 link-switch onto the board.
While that’s generally a good feature, you (and me) might not need the option to reconfigure your Transputer network several times a week… And if you’re completely sure how you like your network it would be better to set if once and for all without the signal delay penalty you have to pay using one or even two C004s.

So in my case, I’m perfectly fine with the 4×4 matrix mentioned in the B012 manual (and also used as an example in my C004 post). So instead of using the clumsy MMS tool and having an extra link used into the T212, I planned tp remove the T212 and the two C004s and replace them with two dummies. Pretty much the same way like Parsytec did it with their x’plorer.
First I had to chew myself through the B012 schematic to understand the connection of each TRAM slot into the C004s. After that it was time for some intense cable plugging:

If you plan to do so, please be aware that the socket holes are too thin for a normal (0.63mm?) jumper cable. You might ruin your socket if you use force to plug them in!
I created a interpose socket by using single row pin header sockets which itself had thin enough pins to fit into the original B012 socket.

After some corrections, the buzzing-through of all 16 slots went fine and the schematics went to the PCB house (I have some PCBs left, ask for a quote if you need some).

And this is how the C004 replacement PCBs look when completed:

Again, to solder in the pins, you’ll need really thin ones. Thinner than 0.5mm that is. Also, you don’t need to populate all 84 pins, I only use 51 per dummy (bridging some gaps).

Additionally, I strongly advise to isolate each dummy’s top with some kind of tape to avoid (electrical) contact to the TRAM placed above it. This is how they look seated on the B012 underneath slot 6 and 14 – the T212 under slot 7 not yet removed:

Software, Transputer Software, Using Transputers

Lies, damn lies and benchmarks

February 15, 2016 Axel Leave a comment

As soon you’re talking about Transputers with people which weren’t there back in 1985 you’ll be asked this very soon: “How fast are these Transputer thingies”? Then there’s a stakkato of “MIPS? Whetstones? Dhrystones?” etc…

As always with benchmarks, the only valid answer is “it depends”. Concerning Transputers that’s even more true.
First, I suggest you read this Lies, Damn lies and benchmarks document from INMOS itself. It pretty much describes the dilemma and all the smoke and mirrors around that matter.

Benchmarks? It depends.

So you’ve read the above INMOS document? As you might saw, it’s full of OCCAM code. That’s the #1 prerequisite to get fast, competitive code (as long you’re not into Transputer assembler). From there it gets worse if you use a C compiler or even FORTRAN…

My little benchmark

Because it scales so well, works with integer as well as floating point CPUs and also runs on the x86 host while using at least the same graphic output routines, my personal benchmark is CSAs Mandelbrot tool (DOS only).
My slightly modified version is part of my Transputer Toolkit, which is downloadable here. You will need that version because I extended the code of this Mandelzoom with a high precision timer (TCHRT, shareware, can’t remove the splashscreen, sorry) when run with the “-a” parameter. You’ll need my provided default “MAN.DAT” file, which contains 2 coordinates to calculate (1st & 2nd run) to get comparable numbers.

So to bench your Transputer system start it with:

man -v -a

which runs it in VGA mode (640x480x16c), loads the coordinates from “MAN.DAT” and when done presents you with a summary screen like this:

To run it on your hosts x86 CPU, call it with “man -t -v -a”

The Results

Here are my results of the different Mandelzoon runs I made in the past. The blue background marks the host machine results, yellow are the integer timings and green is where the mucho macho things are happening.. well, sort of 😉
There are two columns for the results, the HD timer and the hand-timed runtimes. This is because these are from days before I enhanced the Mandelzoom.
This table will continously updated of course. e.g. the last row is pretty new – what might that system be? 😯

The sources are available in my github repository – so we can collaborate on enhancing and optimizing it.

	HD in-programm Timer (s)		Hand-Timed
System	1st	2nd	1st run	2nd run	Comment
i386DX/33 (0kb L2)	1800	0	1:30:00 (canceled)	0	Canceled 1st run after a quarter of Mandelbrot was done…
i386DX/33 (0kb L2) + 387	588	3316	0:09:48	0:55:16
Am386/40 (0kb L2) + 387	490	2980	0:08:10	0:49:40	21% faster clock but only 10.5% better result
i386DX/33 (128k L2) + 387	274	1547	0:04:34	0:25:47
Am386DX/40 (128k L2) + 387	228	1292	0:03:48	0:21:32
i486DX/33 (8k L1, 0k L2)	01:06.24	368.56			Pretty close to a single T800-20
i486DX2/66 (8k L1, 128k L2)	00:33.72	185.51			Very close to 2x T800-20
Pentium 133 (256kb L2)	00:09.09	00:55.01			About 8x T800-20
Pentium 200 MMX	00:07.13	00:38.06			About 9x T800-20
AMD K6-3+/266	00:06.00	00:32.00			Downclocked, 64k L1, 256kb L2, 1M L3
Core i3-2120 3.3GHz	00:01.66	00:02.13			VirtualBox,1 CPU
1x T425-20			0:00:25	0:02:28	There’s something wrong here – needs re-run
2x T425-20	00:51.55	04:56.60
3x T425-20	00:34.42	03:17.81
4x T425-20	00:25.86	02:28.56
5x T425-20	00:20.74	01:58.96
6x T425-20	00:17.37	01:39.19
9x T425-20	11	62	0:00:11	0:01:02
13x T425-20	8	42	0:00:08	0:00:42
21x T425-20	5	27	0:00:05	0:00:27
25x T425-20	4	23	0:00:04	0:00:23
65xT425 (48x25Mhz, 16x20MHz)	00:02.323	00:08.163			Actually it was 64xT800 and one T425 forcing the calculation to integer
1x T800-20	01:09.13	06:27.18
1x T800-25	0:00:55	0:05:09			25% higher clockrate should result in 17.5% speedup. Incl comm-overhead that pretty much fits
1x T800-30	00:00.46	00:04.30
2x T800-20	00:35.65	03:13.79
3x T800-20	00:23.16	02:09.32
4x T800-20	00:17.43	01:37.04
5x T800-20	00:14.04	01:17.74
6x T800-20	00:11.82	01:04.83
5x T800-25	11	62	0:00:11	0:01:02
9x T800-20	8	40	0:00:08	0:00:40
13x T800-20	5	30	0:00:05	0:00:30
17x T800-25	00:03.8	00:18.59			“1st run” shows that the slow ISA interface is really getting a bottleneck
21x T800-20	4	18	0:00:04	0:00:18
33x T800-20	00:02.88	00:11.97
65x T800 (32×25, 33x20Mhz)	00:02.21	00:05.74

GeekDot