Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!decwrl!ucbvax!PUCC.PRINCETON.EDU!09998WAS%MSU
From: 09998WAS%MSU@PUCC.PRINCETON.EDU ("Bill.Simpson")
Newsgroups: comp.protocols.tcp-ip
Subject: IBM VM TCP/IP performance (part 2) revised
Message-ID: <9009190321.AA14869@ucbvax.Berkeley.EDU>
Date: 19 Sep 90 03:21:17 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 79
X-Unparsable-Date: Tuesday, 18 September 1990 5:00pm ET

For those of you who were wondering what in the world Doug Nelson's
spiteful message was referring to, here is the old message, revised
by the helpful comments sent privately (thanks all).  I had given up
on the thread, but it seems the issue has more life than I thought!

This benchmark was conducted over the noisiest line I know of, at slow
speeds, with small packets, with both large and small windows, to
encourage packet loss and demonstrate transmission and syncronization
handling.  With the exception of NIC.DDN.MIL, all testing was done
on a single connection, after midnight -- to eliminate line, route, load,
or congestion variability.

The packet size was 232 bytes.  Optimal transfer bandwidth is:
at 9600 bps: 768 bytes/second
at 1200 bps:  96 bytes/second

NIS.NSF.NET [35.1.1.48] is an IBM 4381P02 running VM/HPO-5 FAL 1.2.1
(according to Merit -- there is no host DNS record).
I understand it to be a lightly loaded machine.  The traces show
less than MSS sized packets, too many retransmissions, timeouts of
20 seconds or more, and failure to combine ACKs with bidirectional data.
The 10 minute transmission timeout causes many RFCs to be unavailable
over serial lines (but may be configurable).  The dir LIST facility
is excruciatingly slow.

at 9600 bps: 320, 353, 299, 382 bytes/second
at 1200 bps:  54,  49

MERIT.EDU [35.1.1.42] is a Sun 3/150 running SunOs 3.5
   the banner says "FTP server (version 4.115 ..."
   (again, no host record)
I understand it to be a heavily loaded machine and therefore to
be running rather slow in its response times.  It is located
on the same ethernet as NIS.NSF.NET, so I thought that it would
make a good comparison for round trip baseline.

at 1200 bps:  77,  85

TERMINATOR.CC.UMICH.EDU [old address deleted] is a Sun-3/160.
   the banner says "FTP server (version 4.172 ..."
It is located a little farther away (6 hops) in another building at UMich.
The distance didn't seem to have any effect (perhaps because it's a T1 link),
and I attribute the improved performance to a lighter load.

at 1200 bps:  92

So I thought that I'd try a little farther!
THUMPER.BELLCORE.COM [128.96.41.1] is a Sun 4/490 running SunOs 4.1.
It is 8 hops farther away than NIS.NSF.NET, over NSFnet and JVNCnet.
None-the-less, the transfer rate is quite respectable.

at 1200 bps:  84

The next week, just for jollies, I tried NIC.DDN.MIL.
The host records says it's a DEC 2060 running Tops20.
It's often difficult to get to, through some incredibly congested
gateways.  I did this at 16:00 EDT, which should be right in the
middle of their working day out west.  I pinged it for 10 minutes,
in 20 sec intervals for a srtt of 2.420 sec and mdev of 0.605 sec;
not counting that 2/3 of the packets were lost!  Even under such
adverse conditions, it outperforms the IBM.

at 1200 bps:  73,  78,  74,  76


CONCLUSION:
IBM-FAL for VM runs at 1/2 the speed of many of its competitors.
It fails to meet several host requirements, not just for TCP/IP
but for FTP and SMTP as well.

Unfortunately, the only product which I am aware of with worse performance
is Spartacus KNET, also for VM.

For the good of the user community, I would recommend to Merit that
the RFC mirror on NIS.NSF.NET be moved to a more capable machine.

Bill Simpson
    09998was@ibm.cl.msu.edu
    09998was@msu.bitnet