Ethernet math (Was Re: MWC's Coherent - A Lemon...)

[John C. Archambeau]

hwajin at daahoud.wrs.com (Hwa Jin Bae) writes:
>In article <2871 at crash.cts.com> jca at pnet01.cts.com (John C. Archambeau) writes:
>   When *I* start seeing consistant throughputs of more than 3 or 4 Mbits per
>   second on an ethernet then I'll agree with you, but until then I write all of
>   this off as the overhead of ethernet.
>
>Kinda like saying: I don't care if there are bunch of people out in the real
>world running 4.3 Tahoe TCP/IP on Sun 3/60's and getting ~8Mbits/sec on 
>ethernets and I personally tell you that I have a system that can do
>~6Mbits/sec on a busy ethernet.
>
>   I don't care what your throughput is or
>   what AST gets on his pair of Sun 3/60's, but what I see when I go and add or
>   setup a network.
>
>Like: if I can't figure out how to make my network go faster, it's not
>my fault, but everyone else's for having done just what I can't seem
>to figure out.  I can always just blame the "ethernet overhead" and
>keep saying "I don't care."
>
>Note, the max throughput limit on ethernet is a fixed value: 10 Mbits/sec.  
>It is not something that changes.  What do you mean by "throughput" here
>anyway?  The raw data transfer rate capacity of any task that talks to
>your ethernet board will depend heavily on the way you wrote your ethernet
>driver and the way your ethernet board itself is designed/constructed.
>Sure, if you have some brain-dead ethernet implementation running with a
>not-so-smart ethernet driver software, and your application is written
>sloppily, your task-to-task data transfer rate will suffer.  This has nothing
>to do with the channel capacity of a given segment of ethernet.  It has
>everything to do with the quality of local implementation: the ethernet board,
>the driver, the application/protocol code.
>
>And, I'm telling you that if you have a nicely designed hardware (like an
>onboard LANCE with enough dual-ported memory or fully arbited on-board
>bus that lets you share main memory between CPU and LANCE) and an ethernet
>driver that utilizes all these hardware design features by "loaning-out"
>LANCE ring buffers to elimite extraneous copying, and a good protocol
>implmenenation like 4.3 Tahoe BSD TCP/IP with all of Van Jacobsen's
>optimizations, and a tightly coded application, ethernet will provide
>you with ample bandwidth to guarantee ~6Mbits/sec even on a "real ethernet",
>and more.  I have this type of systems running here.  Oh, I forgot: you don't
>care.
>
>What you tell me sounds like: well, I've plugged in all these fancy Sun
>workstations and things into my ethernet and they're just pretty slow, so
>don't tell me otherwise, I don't care, etc.  Hey, whatever makes you happy.

I shouldn't have to be an engineer at Novell  or 3 Com to get decent
throughput on an ethernet, but it seems to me that you're saying that I have
to be.  I don't build the networking boards nor do I write the drivers for
them and if you have to spend time going in, ripping apart the ethernet
driver, then that's more work that has to be done in the name of performance
that should've been done by the vendor of the product.

I'm not going to go and take apart everything on the ethernet at both the
hardware and software level since it's not my job for one.  If you want to
go and do it for me, be my guest.

This wouldn't be the first time a vendor screwed up.  And it certainly
won't be the last.

Keep in mind that people often times can't optimize what they have because of
time and/or money.  It's easy for you to say what needs to be done, but hand
the customer the bill on what it costs to do it or change over to the optimal
set up and they very quickly change their mind about upgrading.

Or another even more important limitation, availability.  What if it just
isn't plain available yet?  There isn't much you can do then.  A lot of people
faced this problem when they wanted to upgrade from Netware SFT to Netware 386
just after it came out.  A lot of hardware wasn't compatable with Netware 386
since there were no drivers.  The driver structure in Netware 386 was redone
completely and it was not compatable with its successors.

Go ahead and preach about the optimal configuration, but when you're in that
situation when you're in between a rock, a time limit, and a hard place you
aren't so much concerned with getting it running in the optimal configuration,
you're concerned with getting it running, period.
 
     // JCA

 /*
 **--------------------------------------------------------------------------*
 ** Flames  : /dev/null                     | Small memory model only for
 ** ARPANET : crash!pnet01!jca at nosc.mil     | Unix?  Get the (*bleep*) out
 ** INTERNET: jca at pnet01.cts.com            | of here!
 ** UUCP    : {nosc ucsd hplabs!hd-sdd}!crash!pnet01!jca
 **--------------------------------------------------------------------------*
 */