Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!tut.cis.ohio-state.edu!ucbvax!BARILVM.BITNET!HANK
From: HANK@BARILVM.BITNET (Hank Nussbacher)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: IBM's FAL and poor performance
Message-ID: <9008252315.AA11966@ucbvax.Berkeley.EDU>
Date: 25 Aug 90 21:59:49 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 98

>A month ago, I wrote a very short message to this group concerning
>NIS.NSF.NET, saying "It certainly has a *terrible* implementation
>of TCP/IP."  I quickly received the following private message:
...
>Well, I spent about 15 hours benchmarking NIS.NSF.NET against other
>machines on the internet, carefully documenting the packet traces,
>and passing my observations on to IBM.  I did this at my own expense,
>as a matter of curiousity, because I thought that the folks who were
>sending the messages were "real programmers" who were really interested
>in getting it right (a Jay Elinsky was also involved).

I think in all fairness, you first need to identify yourself.  I have
looked at the Bitearn Nodes database ans was unable to find you listed
as a contact person at MSU.  Can you please describe your position at
the MSU computer center.

>Instead, my messages were sent to Merit, the operator of NSF.NET,
>causing a political uproar.  I personally do not appreciate finger pointing
>as a substitute for action, and in this case it was grossly unjustified.
>
>Let's keep the record straight: the folks at Merit *are* "real programmers".
>In the past, when I have uncovered a problem they have stayed up until
>5:30 in the morning tracking it down (and I suspect without overtime).
>The internet has been vastly improved during the tenure of their operation
>of the NSF net.

I cannot attest to how good the people at Merit are, but I can to the
quality of the people at IBM behind the Tcp/Ip package.  I have not
seen a CERT advisory yet for IBM's VM or MVS Tcp/Ip software but I
have seen quite a few for SunoS (rcp and sendmail to name just 2
recent ones).  To date I have not seen a report where IBM has violated
any IP "rules" and does things fast and loose.  I have seen cases of
vendors called to task in this list and others for ignoring certain
RFC rules, and people have to scramble to make things work around
them.

The people who wrote IBM's TCP/IP code are not reformed Cobol
programmers, but rather true programmers at the bit level.  They
understand all the intricacies of IP and know how to optimize code.

>The NIS.NSF.NET hardware was contributed by IBM, and I understand
>that the software is the latest IBM release.  My benchmark was carefully
>conducted for a direct comparison of the TCP/IP implementations,
>under the worst possible circumstances to make implementation flaws
>stand out clearly.  The failures demonstrated are plainly of the
>host, and not of the environment.

I would like to ask you some questions.  Did you determine whether
Merit is using an IBM 8232 to connect their channel to the Ethernet
or a BTI ELC or ELC2?  The difference is quite astounding.  Did you
check the level of activity on their Ethernet at the time?  If they
had 40% activity, there would be collisions which would cause a
slower response time.  Did you check the VM environment at Merit?
Are their disks fast enough?  Are they properly balanced?  Is Tcp/Ip
getting its full share of the resources?  A simple case where the
anonymous FTP disks you tried to get to being on the same disk pack
as swapping and being located at a sector far enough away, would
cause a slower response time (high seek time and head travel time).

You may be right that Merit "overall" is slower than some other
hosts you have looked at, but that does not mean that the Tcp/Ip
software of IBM is to blame.  It could be the IBM hardware, the
IBM mainframe or IBM VM software mis-optimization.  I will go out
on a limb and state that it is probably not the Tcp/Ip software
which is to blame but perhaps some other aspect, which may explain
why IBM forwarded your note to Merit.

>
>As to the "very satisfied" customers, I will point out that MSU has
>not yet installed the VM TCP/IP product, even though it came "free"
>with other products.  And I occasionally read "IBMTCP-L" on bitnet.
>'Nuf said.

Can you identify some non-satisified customers?  I am a satisified
customer.

>
>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.
...
>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.

Can you elaborate which RFCs it fails to comply to especially in the
FTP and SMTP category?

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

Let's try to keep this a little bit balanced.

Hank Nussbacher