09998WAS%MSU@PUCC.PRINCETON.EDU ("Bill.Simpson") (09/21/90)
> Cliff Frost <cliff@berkeley.edu> or <cliff@ucbcmsa.bitnet> writes: > > I've asked Mr. Simpson (twice) in private mail for the specific failings > of FAL TCP/IP. He has never responded. He still fails to include them. > I'm sorry, I didn't receive your messages. We have a very poor mail system (EMC2/TAO over Spartacus KNET) which drops messages, truncates them, mangles them, sends many of them to the postmaster because it doesn't understand legitimate message headers such as source-routes, and otherwise provides rather unreliable service. Indeed, I haven't yet received the relay of my own message to which you are replying (after 3 days)! Moreover, although I publicly offered to post more complete analysis if there was enough interest, only 3 people asked for it. I really didn't feel that it was worth my time, and the time of the newsgroup. I had already spent half a dozen hours sending private messages on the topic with IBM and Merit. > He went on (in his original posting) to publically criticize the Yorktown > team as substandard programmers, mentioning Jay Elinsky by name. > A few corrections: the word substandard is yours, not mine. I mentioned "real programmers", a term which I substitute these days for "good hacker", which has been rendered a perjorative by the media; I mentioned *two* people by name; and that was the second posting, not the first.... Actually, in the *first* posting, I merely mentioned in an off-hand way that IBM had a terrible implementation of TCP/IP on NIS.NSF.NET. Bill Rubin then *privately* asked what I disliked about their TCP/IP (admitting that they do have a terrible implementation of anonymous FTP). I put in an entire night of benchmarking and packet tracing (at my own expense), and discussed the results *privately* with Bill Rubin and Jay Elinsky, who joined later in the conversation. Now I had thought that I was discussing this with "real programmers" who were really interested in "getting it right". Instead, these fellows sent our private conversation all over IBM and Merit, causing a political uproar; 6 forwards in one case that I know about. In My Humble Opinion, "real programmers" do not publish private mail without permission, and do not start political finger-pointing instead of fixing problems. Let me give a counter-example: a few months ago, I found a case where another implementation of TCP/IP sent a *single* packet with a *single* extra byte when opening the TCP connection (for a total of 41 extra bytes). I pointed out the oversight, and made a suggestion for improvement (publicly, by the way). The programmer welcomed the criticism, and had a new version posted within 3 days! And gained my instant respect.... That's the difference between an ego that says "that's my code -- the problem must be the other guys'!" and an ego that says "that's my code -- I want it to be the best!" As far as I can tell now, the IBM guys were just marketing flacks, who took umbrage that anyone would criticize the IBM product in any way. (They kept saying "we have thousands of satisfied customers".) I never did get a message that any of the problems I found would be fixed. Apparently, they also have thousands of ignorant customers. > Given that Mr. Simpson seems willing to trash people and products by > name and without giving substantial evidence to support his > accusations, it would not be surprising if Doug Nelson responded > spitefully. In fact, I thought Mr. Nelson responded very mildly. > Doug Nelson is responsible for the very poor message system I have to live with, and the message that he posted long after the message thread had died had none of the deep technical information that you seem to demand. Looks like I have to refute and repudiate his message, too. Another day. > 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. Perhaps you think that a data channel on an IBM 4391 has trouble keeping up with 120 bytes per second? How do they run such things as disk drives? My tests were designed to eliminate other considerations such as the Ethernet, gateways, and load. 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. 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). You have wasted 2 hours and 11 minutes of my time. Bill Simpson 09998was@ibm.cl.msu.edu 09998was@msu.edu
kasten@europa.interlan.COM (Frank Kastenholz) (09/21/90)
I've been watching this go on for some time now and actually have been mildly amused by it all. However, I think that this has gone a bit too far..... In a previous life I worked "a bit" on KNET. In fact, I was the development manager of it at the time that IBM's TCP hit the street. Obviously, we at Spartacus had a desire to keep abreast of what was going on with the product. At first it was bad. All products are. It rapidly got better. Most, if not all, of this was apparently due to Jay's efforts. As an ex competitor, I would say that Jay rates being a real programmer (or at least in V=R space :-). I have not been following this area for a couple of years now. Maybe Jay's efforts were "recognized" at IBM so they promoted him out of being a techno-geek into being a management-drone. If so, I'm sorry. To keep the lawyers happy.... This message in no way reflects the opinions, etc, of Racal Interlan, or etc Spartacus/Fibronics. Everything is my own opinion. Frank Kastenholz Ex-KNET-eer
cliff@garnet.berkeley.edu (Cliff Frost) (09/22/90)
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