jas@MONK.PROTEON.COM (John A. Shriver) (04/14/87)
I'll have to repeat the standard incantation about LAN's and network software (at the present state of the commercial art): The software is always slower than the LAN. (Actually, there are some LANs you can buy where this might not be the case, like Appletalk, but any LAN over 4 megabits/second this will be the case.) First of all, the DACU is not, per se, slow. It is truly possible to shove lots of data through it, IBM has really measured speeds well in excess of one Mbyte/sec. (See "Testing the DACU as a Channel Attached PC", IBM form G320-3472.) What is slow is the time/transaction, not the actual transfer rate. Thus, while one can measure 96 Kbytes/sec for 4 Kbyte buffers, this falls to 19 Kbytes/sec for 512 byte bufers. WISCNET and IBM's code are somewhat limited by using small buffers, however they do perform tricks to aggregate multiple packets into one channel transaction and cut overhead. By doing this, one sees typical performance in the 30 Kbytes/second range for FTP. I will soundly agree that the ACC box is somewhat faster at the hardware level than the DACU. A 68000 running compiled code can parse Channel Command Words faster than a PC running interpreted code. Both the DACU and the ACC use the DC-interlock channel protocol. However (no insult to ACC), the ACC TCP/IP will not run at 10 Mbits/sec (1.25 Mbytes/sec) at the TCP or FTP level. One customer I spoke with was getting about 30 Kbytes/sec, about the same as WISCNET. Obviously, both benchmarks are very rough numbers, and one could wage benchmark wars to prove who is better. However, they will always be within an order of magnitude of each other, probably a power of two of each other. My suspicion is that nodoby has broken (or threatened) the 100 Kbytes/sec barrier for TCP/IP on VM or MVS. By the way, that's not shabby, ACF/VTAM is fairly slow stoking 3270's, channel attach clusters aren't much faster than ones off a 56 kbaud line. Basically, if you want to run VM, I'd say go for the DACU/Wiscnet/ProNET solution. If you want to run MVS, choose from the many capable Ethernet vendors and use our router. (If anyone thinks I'm commercially biased towards the DACU, I make more money on a router than on one ProNET-80 board. I just like clean solutions.) BTW, there's been a lot of discussion about things like this on the IBM-NETS mailing list (requests to ibm-nets-request@devvax.tn.cornell.edu on Internet or ibm-nets-request@bitnic on bitnet.)
netnews@orstcs.UUCP (04/15/87)
/* Written 8:22 am Apr 14, 1987 by jas@MONK.PROTEON.COM in orstcs:comp.protocols.tcp-ip */ /* ---------- "Re: tcp/ip/IBM/ProNET" ---------- */ I'll have to repeat the standard incantation about LAN's and network software (at the present state of the commercial art): The software is always slower than the LAN. (Actually, there are some LANs you can buy where this might not be the case, like Appletalk, but any LAN over 4 megabits/second this will be the case.) First of all, the DACU is not, per se, slow. It is truly possible to shove lots of data through it, IBM has really measured speeds well in excess of one Mbyte/sec. (See "Testing the DACU as a Channel Attached PC", IBM form G320-3472.) What is slow is the time/transaction, not the actual transfer rate. Thus, while one can measure 96 Kbytes/sec for 4 Kbyte buffers, this falls to 19 Kbytes/sec for 512 byte bufers. WISCNET and IBM's code are somewhat limited by using small buffers, however they do perform tricks to aggregate multiple packets into one channel transaction and cut overhead. By doing this, one sees typical performance in the 30 Kbytes/second range for FTP. I will soundly agree that the ACC box is somewhat faster at the hardware level than the DACU. A 68000 running compiled code can parse Channel Command Words faster than a PC running interpreted code. Both the DACU and the ACC use the DC-interlock channel protocol. However (no insult to ACC), the ACC TCP/IP will not run at 10 Mbits/sec (1.25 Mbytes/sec) at the TCP or FTP level. One customer I spoke with was getting about 30 Kbytes/sec, about the same as WISCNET. Obviously, both benchmarks are very rough numbers, and one could wage benchmark wars to prove who is better. However, they will always be within an order of magnitude of each other, probably a power of two of each other. My suspicion is that nodoby has broken (or threatened) the 100 Kbytes/sec barrier for TCP/IP on VM or MVS. By the way, that's not shabby, ACF/VTAM is fairly slow stoking 3270's, channel attach clusters aren't much faster than ones off a 56 kbaud line. Basically, if you want to run VM, I'd say go for the DACU/Wiscnet/ProNET solution. If you want to run MVS, choose from the many capable Ethernet vendors and use our router. (If anyone thinks I'm commercially biased towards the DACU, I make more money on a router than on one ProNET-80 board. I just like clean solutions.) BTW, there's been a lot of discussion about things like this on the IBM-NETS mailing list (requests to ibm-nets-request@devvax.tn.cornell.edu on Internet or ibm-nets-request@bitnic on bitnet.) /* End of text from orstcs:comp.protocols.tcp-ip */
Kodinsky@MIT-MULTICS.ARPA (05/02/87)
Speeds iun excess of 100 Kbytes/Second are not unheard of for TCP/IP on
VM. Using KNET/VM on a VM system (true it is a 3090/200) I have seen
speeds peak at about 150 Kbytes/sec. With averages about 85 or 90.
Also, this was not sunday mornging, but the middle of a weekday
afternoon. Other KNET/VM users have reported peaks above 100 Kbytes/sec
Also at spartacus we have peaked at about 55 Kbytes per secoond -
running on a Nixdorf 8890/50 (4331 level machine) and all of our
terminals and disk drives on the same channel - and only one head of
string unit for our disks (for the non S/370 people read that as
extreeeeeemellly sloooooooowwwwwwww).
Now I admit a biased point of view (I am the KNET/VM Development
Manager) and the above is not the full story - on our system during the
middle of the day at abd load times (command response times on the order
of 10's of seconds) I have seen rates drop below 1Kb/second.
My point is that 100KB/Sec has been broken, with production, generally
available products, on production systems experiencing production loads
(not overloads!!!!!).
One final caveat - the speeds that other KNET users may see depend on
many variables and the above speeds should not be used as a guarantee of
the speeds you see ("The milage you get may vary....").
Frank Kastenholz Manager, KNET/VM Development Spartacus/Fibronicsrms@ACC-SB-UNIX.ARPA (Ron Stoughton) (05/04/87)
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