driscoll@ella.SRC.Honeywell.COM (Kevin Driscoll) (11/16/88)
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}w-colinp@microsoft.UUCP (Colin Plumb) (11/17/88)
In article <12025@srcsip.UUCP> driscoll@ella.UUCP (Kevin Driscoll) writes: >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'll see if I can't help. I know a fair bit about the link hardware (ask for the technical note on the TestHardChan instruction - this will give you some documentation on the hardware that's in the transputer), but not much about real-time fault-tolerant packet switching. >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? Well, I'd just have one process per link, but you can have just one doing ALTs four ways (is this what you mean by "do a context"?. On the transputer, you need to know the length of a packet, so you'd need to send a header and body separately. BTW, transputer links (but NOT software channels) behave like byte streams. Sender and receiver don't have to agree on message boundaries. Yes, the links are DMA. I see no reason to restrict the number of simultaneous packets. Have 4 coming in and 4 going out. No, you can't DMA from one link to the other - something like that is rumoured in the T810 (8K+ memory, 8 links, lotsa goodies, >Faster prefix decoding!<), but doesn't exist now. Don't forget that some of that latency you're talking about is waiting for the destination link to come available, so you need to beat it by a bit. But lessee.. With multiple transfers going on, at 20Mbits/sec, I'd expect about 1 MByte/sec effective throughput. Since the message has to be fully received at one node before it's passed on (I think), 20 us latency = 20 bytes. Something isn't gonna work here. You could, I suppose, engage in some nasty tricks by starting the receiver DMA-ing into a memory buffer, and the sender copying out, and hope the receiver is at least as fast as the sender, but there's no way to interlock. How big are the messages you're trying to send? If they're one or two words, I think it could be done, but I wonder if you've thought through what you're asking for - at one megabit per second, which you mention, you're allowing 20 bit-times of latency per node. This is the hardware realm. >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? I know the T425 has overlapped acknowldgements, but I don't know about the T222. If it has >2K of memory, it probably does. Yes, they have the slower bit rates. Look at the LinkSpecial0 and LinkSpecial123 pins. The overalpped acknowledgements do help considerably, especially at the higher bit rates. Can you give me any more info on the routing requirements? I've had some experience with glitches on links, but they were due to reflections (improperly terminated), not jitter. >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? Sorry, we generally use timeouts - but on the order of half a second, which seems unusable for your applications. The problem is that it's impossible to tell how far an in-progress link trasnfer has progressed. (The TestHardChan instruction will tell you, but all 4 links (8 DMA engines) must be idle, or you risk contention on internal buses.) >Are there any other hidden problems in using the transputer for this net? With the trasnputer, there tend to be hidden problems. Maybe if you can mail me more details about the application, I can tell you more. Hope I've been of assistance. -- -Colin (microsof!w-colinp@sun.com)