🚀 go-pugleaf

In article <pi69lek@rhyolite.wpd.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
>35Mbit/sec won't get close to the 8 ms TTRT bandwidth limit.

Yup. Right again.

>There are several well established TCP/IP/FDDI implementations that can
>do > 35Mb/s in a single TCP stream.

Right. And even now, they get jammed down to ~35Mb/s. Like I said, its
an outside issue. I recognize that fixing this is IMPORTANT. I've always been
one of those "want-more-bandwidth-than-you-can-get" guys. But there are some
realities here, and one those is that if you're gonna try and do common-
carrier type things with off-the-shelf internetworking gear, you have
to give up something. Typically bandwidth. Bah. Humbug.

>It sounds to me as if you're situation will need a large TTRT when your
>forwarders start wanting to saturate the link.  It sounds as if any
>hopes based on the slowness of stations are not relevant, since it
>doesn't take many of even the slowest useful FDDI stations to hit 100
>Mb/s in aggregate.

Yes and no. If the demand set being served is lots of 10Mb/s end-to-end
links, then large (or "optimally efficient") TTRT is important to keep
any single node from saturating the net. On the other hand, using the
same basic gear to provide service for a single group of nodes which
need to communicate pair-wise at ~100Mb/s, I've got your problem in
spades. Worse, because I have this common-carrier problem to solve at
the same time.

In any case, multiple rings bridged or routed together will be required.
Which has its own interesting set of problems.

Clearly a case where something LOADS faster than FDDI would be nice....

--
Stanley P. Hanks      Principal Scientist,      Technology Transfer Associates
U.S. Snail:        P.O. Box 2087,   Bellaire    TX    77402-2087
FedEx/Shipping:    5303-F Glenmont, Houston     TX    77081
e-mail: stan@karazm.math.uh.edu   voice: (713) 661-2084     fax: (713) 661-0633