Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!rutgers!ames!ucbcad!ucbvax!ACC-SB-UNIX.ARPA!rms From: rms@ACC-SB-UNIX.ARPA (Ron Stoughton) Newsgroups: comp.protocols.tcp-ip Subject: re: tcp/ip/IBM/ProNET Message-ID: <8705032318.AA15714@ACC-SB-UNIX.ARPA> Date: Sun, 3-May-87 19:18:00 EDT Article-I.D.: ACC-SB-U.8705032318.AA15714 Posted: Sun May 3 19:18:00 1987 Date-Received: Tue, 5-May-87 01:16:30 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 96 I would like to comment briefly on David Young's suggestion and John Shriver's reply regarding using ACS 9310's and a ProNET gateway to interface an IBM system to ProNET. The purpose here is not to beat our chest, but to clarify what the 9310 can and cannot do. First, there was an inference that the ACS 9310 could run at the full speed of the Ethernet. As John correctly pointed out, this is not quite true, or is at least misleading. While it is true that the channel interface will run at the full speed of the block multiplexer channel, and the Ethernet interface will run at the full 10Mbps speed of the Ethernet, the *sustained* throughput capacity is somewhat less. We have measured a sustained packet rate of 3600+ packets/sec at the channel interface, and 2700+ packets/sec at the Ethernet interface. However, the software glue which binds these together drops the total capacity to 350 packets/sec (it's amazing what programmers can do). One should note that the main bottleneck is the memory-to-memory transfer rate across an internal system bus which interconnects these two subsystems. Incorporating a hardware DMA would significantly improve system throughput. [I should point out that the 9310 does more than just simple pass-through between the channel and the network. For example, all ARP processing is done in the interface, and for historical reasons, IMP emulation is performed there as well.] Second, whether or not the 9310 is faster than the DACU (it is) should not be the only consideration. In particular, the effi- ciency of the channel protocol can significantly impact system performance. I am not intimately familiar with the DACU, but I believe it emulates 3250 commands to transfer data. Like other IBM control units, this is half-duplex and requires attention interrupts. The 9310 uses two independent subchannels to provide a full-duplex interface. Someone in our office once looked at some code which interfaced to a DACU and counted 10 channel inter- actions to transfer some data and read a response. Hopefully the Wiscnet driver was not done in this manner, but nevertheless, a halfduplex interface will certainly result in more interrupts. Third, John's assertion that even if the hardware could run at the full speed of the network that the host software could not, is certainly true. However, I do not agree that the 100Kbytes/sec barrier has not been broken or threatened. Lacking anything faster than a VAX 750, we did some file transfers to ourselves (a 4341-2 running ACCES/MVS) by looping within the 9310. We measured 50K bytes/sec in each direction. While this is not a 100kbytes/sec file transfer, it is exactly equivalent to two simultaneous 50K bytes/second transfers, or an aggregate of 100Kbytes/sec through TCP/IP and FTP. It should also be pointed out that the 9310 averaged less than 40% busy which is consistent with its 350 packets/second capacity. Extrapolating, and assuming no coalesc- ing of TCP acks, it should be possible to transfer an aggregate of 262Kbytes/sec. In an attempt to find out why we could not drive the 9310 to saturation we repeated the above tests, but looping at the EXCP level instead of in the 9310. In otherwords, output packets were copied from the output buffer into an input buffer instead of being transferred across the channel (to the 9310). Even with the additional buffer copy, we measured an aggregate of 260Kbytes/sec. The difference (160Kbytes/sec) is apparently attributable to IOS interrupt processing and MVS dispatching overhead. This was surprising to me, but not inconsistent with MVS's reputation of being an I/O klutz, particularly on small mainframes. Additional interrupt processing because of half-duplex handshaking would only make matters worse. I tend to agree with John that we should avoid benchmark wars since the numbers are often meaningless without proper context. Also, such tests are often conducted under optimum conditions which may not apply to the garden variety file transfer. For example, rates are usually quoted for binary transfers, whereas most file transfers are in ASCII. In regard to using a 9310 + ProNET gateway to interface a VM system to ProNET-80, our sales people are certainly not going to refuse to take your money. However, I am not sure the performance benefits are necessarily acheivable at this time. For example, what is the performance threshold of the Wiscnet software, and what is at the other end of the network connection (you can't send data faster than the other end is willing to receive it)? The deciding factor may be the amount of CPU resources a user is willing to expend to acheive a given level of throughput. Some more definitive information may be forthcoming. We are having a new driver developed for Wiscnet which should be much more efficient than the driver which comes with 5798-DRG (or now 5798-FAL). As part of this effort some benchmarking will be done. Anyone interested in the results should contact me and I will send you the information. If I have offended anyone's sensibilities by appearing commercial, I apologize. This was not the intent. Ron Stoughton ACC