Conference 7.286::fddi

    
>    In a similar vein does anyone know of like studies/findings/models for
>    Ethernet performance issues ?
    
I have a poor copy of a paper titled "Measurement Of A Large Local Area 
Network" from John M. Lewis, DEC. I believe it was published in one of the
network related DECpress books.

I think that arbitrartion is more of an issue than `protocol header length'.
There are a lot of factors that go into this, including the settings of
certain operational parameters.

Are you sure you really want to know?

There are a lot of factors to consider and many are inter-related.

The real problems are going to be fast adapters and protocol engines.

    Further clarification of requirements.....

    Thanks for the replies guys - I have seen the report you describe
    Dieter and others from WRL by David Boggs & Co. too. I also realise
    that my question tends towards the "how long is a piece of string ?"
    naivety we usually level at our customers ! 

    However, that is precisely where I'm coming from - a customers view of
    networks and performance !

    What I would like to find (somewhere) is a "reasonable" expectation of  
    performance throughput that users can expect from using DECnet etc.    
    over Ethernet and FDDI. TCP/IP would also be useful !

    I think we're guilty of defending our systems by trying to blind the
    customer with reasons for not giving such figures or telling them how
    difficult it is without knowing the actual configuration and use etc.
    etc. And all the time the customer is likely to be quite happy
    knowing that with X, Y and Z as a reference starting-point he's likely 
    to achieve 2Mbps from Ethernet and 60Mbps from FDDI - or whatever it is ! 

    I regulary get customers asking such questions so that they can "model"
    their networks to suit requirements and I must admit to feeling more
    than a little embarrassed when I cannot give a "decent" answer.
    
    We tend towards "Digital's experience with networks shows that....." or
    "Would you like to make use of our Network Monitoring Tools...." which
    tend towards waffle in the first one and potential overkill/lateness in
    the latter.
    
    In a similar vein we get queries around the use of bridges to isolate
    LAVC workgroups and the customer asks "Why do I need one ?" "At what
    point do I need one ?" Without a model to base calculations on are we
    not guilty of "You need one because its a LAVC !" ie. regardless of
    need...
    
    Sorry if I'm wandering from FDDI somewhat, but I feel its all related.
    How can we possibly propose ourselves as the experts in networking if
    we cannot substantiate the claim by providing capacity planning tools
    and models for networking - or more simply, "rules of thumb"
    guidelines ?
    
    If there are such tools please point me in their direction.
    
    If you've got this far - thanks again
    
    Rog 

I have to agree with and relate to .0 and .3.  I recently had a customer request
to help them attain 80Mbps transfer rate between two systems (on FDDI).  The
systems were stated as a Convex model C-220 and a VAX 6330.  The volume of data
in each transfer is between 5-20 Gbytes (I assume an imaging application).

I don't think that FDDI or any other "general purpose" LAN technology at any
speed is the answer.  But what else is there?  I mean something that is clean
and supported by a reputable vendor.  It seems to me that Digital, among other
vendors is not looking at the bigger picture when it comes to moving LARGE
amounts of data and interfacing with the compute engines that are designed to
handle these volumes of data.  In the application above, what is needed is a
high speed massive parallel bus (64-128 bits wide) interface.  After attending
an imaging seminar (by DEC), I left feeling that SCSI bus interfaces through
native bus adaptors just won't cut it.  Imaging has arrived... but has anyone
looked at our total I/O capabilities?  I have to feel sorry for our customers
who listen to (and believe?) marketing hype around these grand applications that
will virtually take our latest hardware technology to its knees.

Yes, I feel better now.

So I guess, in a perfect world, everything would be considered in design, and
support people like me could obtain accurate throughput estimates for systems
and networks and the customer would be happy.  But here we are, today, in the
real world armed with reams of hype and theoretical, best-case, application-less,
statistics selling "solutions" to our customers.  It would be really nice to
know approximate transfer rates from disk, through system, to network for
applications like BACKUP or COPY or custom QIO etc. for the major
classifications of disks, systems, and networks.  I know that BACKUP is much
faster than COPY, for various reasons, but how much faster.  When you move
20Gbytes of data around, you might like to know how long it would take...
minutes, hours, days?  Sometimes the customer cares, and wants to know.

>
>Yes, I feel better now.

	:-)

>So I guess, in a perfect world, everything would be considered in design, and
>support people like me could obtain accurate throughput estimates for systems
>and networks and the customer would be happy.

	And therein lies the real problem. In order to consider "everything
	in design" you have too many unknowns. ONe of the biggest unknowns
	is what else the customer will decide to do with the system once you've 
	sold it.

	You can calculate and model and figure to the Nth degree against
	what they say they will use the machine for. But after they've
	installed it, and Joe User gets his paws on it, the system can 
	(and very often does) end up running applications that it was not 
	intended to,with a loss in performance for the applications that 
	it was intended to.

	I'm just playing devils advocate. I am not trying to belittle the 
	importance of having this kind of data available for marketeers.
	Just pointing out the need for these disclaimers that must go out
	with any performance promises.

							Bill Salkewicz
							VMS Development

    
    Bill
    
    >> You can calculate and model... on the system to the nth degree...
    
    Where are the models ? Are we talking the SYSTEM here - what about the
    network ?
    
    I agree that we should be guarded in our use of such data but it would
    be very useful to have something upon which to base assumptions of
    achievable throughputs - rather than the more usual "finger in the air"
    approach... :-}
    
    Regards
    
    Roger
    
    

    Actually, you could also go the emperical route,.. actually setting up
    systems that do "something" and measure their performance. Of course,
    you would need to do a lot of extrapolation since the chances that the
    same system you are trying to sell has been set up and measured are
    about one in a million.
    
    The nature of the problem makes it difficult. The number of variables
    are too high. I'm afraid that if I did propose a model (or anybody
    else did) that at least 90% of the people who wanted this kind of data 
    would say that our model was wrong.
    
    I'd like to say there was an easy answer, but I don't think there is
    one. Perhaps we could start by gathering the descriptions of "typical"
    systems, and then model or measure those systems. I would think that if
    the sales force was having trouble making sales because of a lack of
    this kind of data, that they would be willing to appropriate resources
    to get the data. Perhaps the resources need to be appropriated at the
    corporate level,.. I don't know. But if this problem is really as big
    as you seem to think, why not raise it up the channels. I don't think
    a note in this conference is going te get you what you want/need.
    
    I know that there are some detailed performance studies that have been
    done for VAXclusters, but I have no idea if they would be of any value
    to you. 
    
    								/Bill