Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!julius.cs.uiuc.edu!apple!agate!garnet.berkeley.edu!cliff
From: cliff@garnet.berkeley.edu (Cliff Frost)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: the flaming fool
Message-ID: <1990Sep21.192753.21356@agate.berkeley.edu>
Date: 21 Sep 90 19:27:53 GMT
References: <9009210717.AA21143@ucbvax.Berkeley.EDU>
Sender: usenet@agate.berkeley.edu (USENET Administrator)
Reply-To: cliff@garnet.berkeley.edu (Cliff Frost)
Organization: University of California, Berkeley
Lines: 56


In article <9009210717.AA21143@ucbvax.Berkeley.EDU>,
09998WAS%MSU@PUCC.PRINCETON.EDU ("Bill.Simpson") writes:
|> > Cliff Frost <cliff@berkeley.edu> or <cliff@ucbcmsa.bitnet> writes:
|> >
...
|> > Unless Mr. Simpson comes up with some previously undisclosed facts the
|> > only conclusion to draw is that he is nothing more than a "flaming"
|> > fool.  Yes, the throughput from NIS.NSF.NET is low.  No, that does
|> > not prove the software on the machine is to blame.
|> >
|> Perhaps you have some other explanation...

Yes, there are any number of other plausible explanations for the data
you had publically posted, although my statement should have read:
"...does not prove the TCP/IP software on the machine is to blame."

For example, a VM machine with improperly configured scheduling can
absolutely destroy TCP/IP performance; for example by keeping the code
from running when it needs to.  No amount of cleverness by the TCP/IP
programming team could make up for this.

|> As for flaming fools, I will note that you have at least 2 public flames
|> without so much as a single counter-example, alterative test data, or
|> other objective criterion on which to base your criticism.

This is a lie.  My very first posting on this subject (the one you are
quoting from!) contained possible alternate explanations for 3 specific
problems you mentioned:

1)  "less than MSS sized packets"	
	Packet size is configurable in a couple of ways in that product.

2)  "too many retransmissions"
3)  "timeouts of 20 seconds or more"
	Trivial to accomplish by misconfiguring the VM scheduler
	(that is, nothing to do with the scheduler in the TCP/IP sw.)
	    
Without the data that you *finally* produced there was no way for us to
rule those theories out.

|>   My benchmark
|> is readily verifiable by anyone who wants to take the time
|> (and as I clearly stated in "performance part 1", has been verified).

I have never challenged either your benchmark or your assertion that there
are problems in the software.  What I said was that you had not given us
enough information to evaluate the substance of your criticisms of it. 
You posted the ambiguous data 3 times, so I can't imagine why you hesitated
to post the real data--it's both shorter and much more interesting.

I will say that in my experience, Bill Rubin and Jay Elinsky have been
both "real programmers" and very responsive to customers problem reports.
We're all aware by now that you feel differently.

	Cliff Frost