AUERBACH@CSL.SRI.COM.UUCP (10/02/87)
Thank you all for all the comments. It seems that if one can get a net with high enough bandwidth, low enough error rate, and short enough delay, that TCP could, in theory, consume a significant portion of the available bandwidth. An example of the net that raised my initial question is the Los Alamos CP* net which will run its links at 640Mbits/sec. Total capacity of the net will be on the order of 20G (yes that's a 'G', not an 'M') bits/sec. Lengths are short, so delays will probably be less than a few thousand bit times (i.e. much less than a millisecond. The end nodes will be Cray X-MP, Cray 2, and faster. (At 640Mbits it only takes about 8 milliseconds to transmit a full segment!) What bothers me the most is that we've had HYPERchannels for a long time and 80meg Proteon rings for a while, but the highest TCP value I heard was about 17megabits. Why the discrepency? Is it something intrinsic to the TCP protocol (and probably in ISO TPx as well) or in the implementations or hardware? --karl-- -------
CERF@A.ISI.EDU (10/02/87)
Karl, Even when you aren't hurt by delay, CPU speed can prevent full bandwidth achievement - I would guess that for the high speed nets, CPU resource has been the limiting factor. Vint
ron@TOPAZ.RUTGERS.EDU (Ron Natalie) (10/04/87)
If you think that TCP is bad, you should try some NETEX bandwidth studies on the Hyperchannel. It's beyond me how they can make a protocol custom to the hardware like that and do it so poorly. Don't forget that it is frequently difficult to get more than 50% of the available bandwidth (some Pessemists law). My major problem with the 10M proteon (which I doubt was changed much in the 80 M version) is that there is no buffering on the card. If in servicing the last packet you frequently miss having the card ready for the SOM on the next packet. This packet has to bounce around the ring again. Another problem is that 17 Mbits is rapidly the DMA limits of most of the cheap interfaces (That IS the speed of the UNIBUS). -Ron
jas@MONK.PROTEON.COM (John A. Shriver) (10/05/87)
Are there any published studies on NETEX performance? It would be good if the world could learn from the frustrations of the past. One of the interesting limits that has not been mentioned in the discussion is the programming interface. While I've never written a "sink" protocol family for 4.xBSD, I did write a "sink" driver (if_bb.c, for "Bit Bucket"). I found that even UDP can't feed the driver all that fast on a Sun. The same probably applies to the socket() interface itself, which could be tested with the "sink" protocol family. Proteon did adress the obvious problems of packet buffers in ProNET-80. All of the boards have at least 3 on the receive side. Some have 16KB of memory that holds as many packets as fit. The VMEbus allows you to implement DMA at speeds over 100 megabits/second, which allows the ProNET-80 VMEbus card to move data from ring to bus RAM at 80 mbps.
kline@UXC.CSO.UIUC.EDU (Charley Kline) (10/08/87)
NSC did a few studies on NETEX performance at the last NEXUS I was at.
The performance numbers varied about linearly with the crank of the
particular CPU's involved, indicating an inefficiently coded protocol.
If you're interested in the theories of Hyperchannel hardware performance
(which is crucial if you're trying to put new protocols on Hyperchannels),
a paper by Franta and Heath, "Performance of Hyperchannel Networks" is
excellent reading. I have hard copies if anyone is interested.
-----
Charley Kline
University of Illinois Computing Services
Internet: kline@uxc.cso.uiuc.edu
Bitnet: kline@uiucvmd.bitnet
UUCP: {ihnp4,seismo,pur-ee,convex}!uiucdcs!uiucuxc!kline