Path: utzoo!attcan!uunet!husc6!bloom-beacon!tut.cis.ohio-state.edu!cwjcc!hal!nic.MR.NET!shamash!nis!ems!srcsip!ella!driscoll
From: driscoll@ella.SRC.Honeywell.COM (Kevin Driscoll)
Newsgroups: comp.sys.transputer
Subject: suitable for realtime packet net?
Keywords: real-time, links, context switch, fault tolerance
Message-ID: <12025@srcsip.UUCP>
Date: 16 Nov 88 08:43:17 GMT
Sender: news@src.honeywell.COM
Reply-To: driscoll@ella.UUCP (Kevin Driscoll)
Organization: Honeywell Systems & Research Center, Camden, MN
Lines: 40

I am trying to determine if I can use a transputer for a fault tolerant
real-time packet network.  Because of the real-time constraints, I need low
latency at about one megabits/sec.  Source to destination latency will be the
sum of the latencies in each of the intermediate nodes.  The total must be less
than 500 microseconds and there may be 20 nodes in the path, so the latency at
each node must be less than 25 microseconds.  Inmos has given me hundreds of
pages of documentation, but none of it gets into the real nuts and bolts of how
the transputer and its links work.

I need to know how fast data can be shuffled in one link and out another.
Assume the following scenario:  the transputer normally is doing a low priority
task unrelated to its links, a packet of unknown size may arrive on any link at
any time.  How can the transputer be set up to do a context on any link input?
How does it know that a byte has arrived?  Do the links use DMA?  If so, can
the source and the destination both be links and how many cycles does a DMA
transfer need?  How fast can the whole process be done?  Would an external
limit of no more than two packets arriving simultaneously help?

Because of routing constraints on the links, it may be difficult to meet the
jitter requirements of 10 megabits/sec speed.  Is the T212 the only part to
have a 5 megabits/sec speed or does the T222 or T425 have this speed?  Do these
newer parts use concurrent acknowledgement and does this significantly speed up
transfers compared with the sequential acknowledgement used by the T212?  Has
anyone had experience where jitter was a problem?  Can better crystal matching
buy any extra jitter tolerance?  Are there any other tricks to help the jitter
problem?  Does any transputer part have a wider jitter margin than the others?

What is the best way to tell if a link is down considering the real-time
constraints?  Put a time guard on each transfer?  Use a limited elastic buffer
and test for limit violations?

Are there any other hidden problems in using the transputer for this net?

Any answers to any of my questions would be greatly appreciated.  Thank you.
 -----
Kevin R. Driscoll, Principal Research Scientist    (612) 782-7263   FAX: -7438
POST:  Honeywell M/S MN65-2500; 3660 Technology Drive; Mpls, MN 55418-1006
INTERNET:  driscoll@{src,altura}.honeywell.com
UUCP:  driscoll@srcsip.uucp   or   {umn-cs,ems,bthpyd}!srcsip!driscoll
MIXED:  srcsip!driscoll@umn-cs.{cs.umn.edu,arpa}