sblair@upurbmw.dell.com (Steve Blair) (01/22/91)
[the following are *MY* opinions, and >not< DELL's] Having recently left a networking company in Ca., I spent about 4 months working with FDDI. A few observations that I observed while working with several FDDI TCP/IP implementations: 1) the only way almost anyone will every get close to 100Mb's/sec is if nothing is running on the network, and TCP/IP doesn't exist. 2) TCP/IP over FDDI was only successful in gaining a B/W of about 45->60Mb's/sec in "normal" operation mode, and in "burst" mode, mabye about 65->72Mb's/sec. 3) TCP/IP is notoriously ineffecient as a statefull protocol on "any wire". Therefore, that's one of the reasons that on a fairly quiet network, you'll only see about 4->6.2Mb's/sec *due to the statefull overhead* of TCP/IP. FDDI does/will add significantly to the networked performance of many systems, and applications that are written to take advantage of the increased bandwidth. However, there are other mitigating issues that can(*and do*) hamper effeciency on a network(FDDI). Some of these issues are: 1) not all vendors are racing to adopt/implement FDDI until the marketing/compatibality issues are "wrung out". 2) FDDI has certain information that in restructuring the "ring": after a failure takes sometime to occur. Also there are other packets, like scrubber packets, that consume some network overhead, just like routing information does. Hopefull this will help. *YOUR MILEAGE WILL VARY* steve blair DELL UNIX DIVISION
vjs@calcite.UUCP (Vernon Schryver) (01/22/91)
In article <14325@uudell.dell.com>, sblair@upurbmw.dell.com (Steve Blair) writes: > 2) TCP/IP over FDDI was only successful in gaining a B/W of about > 45->60Mb's/sec in "normal" operation mode, and in "burst" > mode, mabye about 65->72Mb's/sec. > 3) TCP/IP is notoriously ineffecient as a statefull protocol on > "any wire". Therefore, that's one of the reasons that on > a fairly quiet network, you'll only see about 4->6.2Mb's/sec > *due to the statefull overhead* of TCP/IP. This is not consistent with my experience as an implementer. I know of about 5 commercial, released implemenations, including my own, that get well over 10Mbit/sec thru TCP/IP/FDDI as measured by TTCP. I know of more than one >30Mb/s, tho not necessarily released. There are good rumors of higher FDDI numbers, but honesty becomes scarce above 50. (If it can't do close to 100Mbit/sec in a burst, say 100KBytes, I think it's broken.) As long as T_NEG is reasonable (say >=8msec), and as long as the total traffic on the ring is <100Mb/s, you don't need to worry about keeping the network quiet. I make my speed measurements on a ring also used for operational NFS, SMTP, etc. I get dozens of Mbit/sec continuously and indefinitely (necessarily measured by counting packets with a 3rd machine). The "TCP is slow because ineffecient" is a familiar statement. It is no longer popular since being disproven. Perhaps the simplest academic proof is Van Jacobson's count of the number instructions to handle a TCP/IP packet on a Sun, from interrupt to delivery, excluding checksumming and byte copying. As I recall, his number (for his code?) was ~200/packet. Less academic is that between some CRAYs and some workstations, ULTRA gets ~13MBytes/sec TCP/IP over their proprietary link layer. > FDDI does/will add significantly to the networked performance of many > systems, and applications that are written to take advantage of the > increased bandwidth. ... There is little a well written program can or should do for FDDI. Big buffers and big windows are smart, but that's true on all but the slowest media. This is good and bad news. I doubt FDDI would do much for a PC, from XT to 486, but make it slower. However, fast machines with better buses, which already saturate Ethernet with TCP/IP, can gain by using FDDI to peers. > 2) FDDI has certain information that in restructuring the "ring": > after a failure takes sometime to occur. Also there are > other packets, like scrubber packets, that consume some > network overhead, just like routing information does. One vendor (whose performance numbers I do not recall, and so did not count above) became unpopular at a recent trade show (unnamed to avoid being sued by the show managment) because of their purger (sic) frames. These are controversial and in my view naively implemented, but their bad effects do NOT include consuming usable bandwidth. While the ring is stable (ie. all of the time in normal circumstances), there are no overhead frames consuming significant usable bandwidth. I'll forebear chanting chapter and verse of the several standards in public. This follows the ANSI X3T9.5 party line that NIFs, PRFs, SIFs, and SRFs are not significant, which is manifestly true in small rings, and where T_NOTIFY is at the standard 30 seconds. It also assumes the human ring managers have not gone crazy with T_NEG. Vernon Schryver, vjs@sgi.com