Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!amdcad!pepsi!ching
From: ching@pepsi.amd.com (Mike Ching)
Newsgroups: comp.arch
Subject: Re: One aspect of bandwidth (backplane bus)
Message-ID: <25368@amdcad.AMD.COM>
Date: 23 Apr 89 05:52:45 GMT
References: <407@bnr-fos.UUCP> <17500@obiwan.mips.COM> <17527@winchester.mips.COM> <25241@amdcad.AMD.COM> <199@gvlv2.GVL.Unisys.COM> <1989Apr22.225625.5883@utzoo.uucp>
Sender: news@amdcad.AMD.COM
Reply-To: ching@pepsi.AMD.COM (Mike Ching)
Organization: Advanced Micro Devices, Inc. Sunnyvale CA
Lines: 18

In article <1989Apr22.225625.5883@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes:
 >In article <199@gvlv2.GVL.Unisys.COM> kleonard@gvlv2.GVL.Unisys.COM (Ken Leonard) writes:
 >>...We haven't completely figured out how to deal 
 >>with the "where-to-send-this-piece" info for a given "block" as fast as we can 
 >>move the piece...
 >
 >Are you familiar with Chesson's "protocol engine" work?  He's looking at
 >a fully general virtual-circuit protocol that can keep up with 100Mbps FDDI.
 >Yes, it's done in hardware.  The protocol is carefully organized so it can
 >be processed "on the fly", i.e. the hardware can keep up with 100Mpbs
 >indefinitely, not just in bursts, provided there's somewhere for the data
 >to go at that speed.

Actually 100Mbits is the low end of the range being addressed by the protocol
engine. The intent is to have a protocol and hardware that can support future
gigabit networks as well as the current 100megabit one.

Mike Ching