Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!decwrl!ucbvax!cam-orl.UUCP!br From: br@cam-orl.UUCP (Brian Robertson) Newsgroups: comp.sys.transputer Subject: Re: i860s and the like Message-ID: <90.08.10.11:36.800.br@mango> Date: 10 Aug 90 10:36:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 74 >>If a manufacturer produced boards with a t800 coupled with link driver >>hardware that ran at 10 times the speed of the t800's links, then I would >>be able to use ten times as many processors, and get 10 times the >>performance. What about it? >Why not just scrap the t800 completely? Take the i860 hook it to >some memory with a hardware message router (like Ametek had) and let >it rip. It would blow the transputer networks out of the water. Look >at what Intel is doing with the IPSC. Inmos is effectively doing just that by bringing out the H1. However its never called being scrapped. The H1 will be code compatible with the T8 and will have all the things in it to do routing for free e.g. virtual cut through. The T8 will then be made cheaper. When demand for the T8 falls too low then the T8 will be scrapped just like the M2. The transputer I believe is forward looking in two respects. First it recognises that processor speed for a given technology will eventually saturate and that to go faster we will need to use parallelism. Second with the increase in integration it allows memory and glue logic to be put on chip and to run alot faster than if the memory and glue logic were off chip. >A couple of points: >1. With a faster processor, you don't need as many processors, hence there >is less message passing to begin with. That is exactly what happened to >us--the T800's were not very fast and just adding more of them would >have created a communication nightmare. The i860's with the extra links >solved two problems for us. We could do the problem with just a few >(from 8 to 32) processors, and the multi-hop overhead and link >contention went away. If you continue the trend, you can eliminate >the need for parallel/multi-computers in the first place. Another advantage of the transputer is being able to implement what I call object oriented HW. If a design is divided up into logical HW modules then the HW and SW become very simple to write. Only the interface need to be specified to the module. The HW interface should be standard (ideally between manufacturers). Only the SW interface needs to be specified. By making things simple they become more reliable and easy to implement. The board dimensions of the module are kept small, which is useful as clock speeds go up. It becomes much more easy to build systems as all that is necessary is to configure standard modules together. This has advantages for the all important time-to-market parameter. This is why I believe the TRAM concept is so good. What is true is that the prices of these off the shelf TRAM modules are too high. As clock speeds increase then 'kitchen sink' boards will become increasingly more difficult to build. Capacitance and inductance will mean that crosstalk, and ringing will increase. Parallel connections will have more skew problems. This alone will mean that serial interfaces will start to have advantages in providing transport even over quite short distances. Monomode fibre with huge BW possibilities is obviously attractive but still expensive. What is a shame is that Inmos may decide to keep the new H1 HW interface protected and so prevent other manufacturers from being compatible. I would like to see not only faster interface but 'standard' interfaces between manufacturers devices. Even now, conventional 'kitchen sink' boards are not in practice uniprocessor devices. The ethernet, rs232 or whatever, are all controlled by dedicated processors. How they communicate is completely non standard, some have dma built in some dont, etc, etc. Often on these boards the shared data busses have severe disadvantages especially in real time applications. For example it is not possible for too many ethernet controllers to share the same bus as they may all fight for the bus at the same time. Local processing/filtering/buffering may often be required to solve these problems. In addition physical separation may also be required so that control can be provided where control is needed e.g. in robot applications. There are also applications where a uniprocessor is perfect. Brian Robertson Olivetti Research Cambridge. UK.