Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!ames!ucbcad!ucbvax!hplabs!hp-pcd!orstcs!netnews
From: netnews@orstcs.UUCP
Newsgroups: comp.protocols.tcp-ip
Subject: Re: tcp/ip/IBM/ProNET
Message-ID: <780300005@orstcs>
Date: Wed, 15-Apr-87 13:11:00 EST
Article-I.D.: orstcs.780300005
Posted: Wed Apr 15 13:11:00 1987
Date-Received: Sat, 18-Apr-87 04:35:13 EST
Lines: 56
Nf-ID: #N:orstcs:780300005:000:2668
Nf-From: orstcs.cs.ORST.EDU!netnews    Apr 15 10:11:00 1987


/* 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 */