🚀 go-pugleaf

In article <1992Oct27.175911.8809@alf.uib.no>, jan@ii.uib.no (Jan Henriksen) writes:
|>There's been several suggestions on this question. I still believe
|>that our observation is correct, and that this -somehow- is an 
|>implemation issue. Here's a short cut from a 9-month old email message:
|>
|>> 2. Your second question had to do with the BSI.
|>> 
|>> 	Yes you are right my answer was wrong (I'm sorry).  The NS chip
|>>	does support multiple pkts per token.  However, our implementation
|>>	of the BSI does not support this feature.
|>
|>At the time it was not a big issue, now it may become one. Note that
|>we're observing ~50Mbps throughput with this adapter (ttcp -l50000), 
|>so it is not exactly slow either. Applications using TCP have observed
|>throughput of ~3000KB/s, and as I stated previously, 'tcpdump' will
|>show that packets are being sent at approx. 1ms intervals. The application
|>uses a 48KB packet-size, leaving all questions of fragmentation and
|>physical network packet sizes to the network protocol layers.
|>
|>It would be useful if I could get a hands-up/down from vendors, about
|>whether they have implemented this feature or not. It's my impression
|>that not many *have*, but there is only one vendor that I have thoroughly
|>scrutinized, and where I feel comfortable about giving opinions ...
|>
|>-- 
|>Jan Berger Henriksen
|>Institute of Informatics		E-mail:	jan@eik.ii.uib.no
|>University of Bergen
|>H|yteknologisenteret
|>N - 5020 Bergen,			Phone : 47-5-544173
|>Norway					Fax   : 47-5-544199

Digital does support this feature in all FDDI products.

(I agree with Vern Schryver on this issue: it seems to make very little
sense to implement a product that does not implement it.  Such a product
would by definition be low-performance, and if you're not going to be able
to use a substantial fraction of FDDI bandwidth, why bother?)

	paul