Conference 7.286::fddi

    Sadly, that's not a question of device drivers.  If only the use of
    parallel adapters were a simple change at the driver level, we'd be rich.

    Do you want the host system to split its traffic to multiple destinations
    across multiple adapters in a load-balacing fashion?  Or do you want it
    to split the traffic to a single destination across the adapters as well?

    When sending to multiple destinations, certain host transport-layer
    software (such as VMScluster's SCS) knows how to use several adapaters
    to reach several other systems.  In addition, some OSI network-layer
    implementations know how to use multiple paths (e.g., multiple LAN
    addresses) to spray packets quickly to a single destination.  However,
    I don't know if the "DECnet/OSI for OpenVMS Alpha" or
    "DECnet/OSI for DEC OSF/1 for Alpha" software products know how to spray
    packets to multiple LAN addresses and over multiple source adapters.
    (Aren't middleware product names getting complicated?)

    The effective use of multiple adapters beyond VMScluster's SCS is an
    important item for engineering to enhance, just like the deployment of
    full-duplex support in each model of FDDI adapter.  I don't have any
    schedule or software version guesses on this.  Can anyone correct me
    that these features have not been announced yet for a DECnet/OSI kit?

    As you can infer, the use of multiple adapters by DECnet software is
    not just an FDDI issue.  If multiple Ethernet adapters were installed,
    you could ask the same question for increased performance.  (Imagine
    that all of the Ethernet adapters were bridged to one FDDI ring--a poor
    man's Ethernet switch.)  So, repeat your question in the DECnet Phase V
    conference, and in the TCP/IP conference (whatever that is).

    Thanks for the info. To answer your questions, I'd like the adapters to
    do both, share the adapters to multiple destinations for load-balancing
    and also send info to one destination (e.g. a disk array). The customer
    I was talking to has the requirement to send/receive GBYTES of data per 
    second over the net to either other hosts or disks.
    
    I'll post this in the DECnet Phase V notesfile as well as the TCP/IP
    one. Anyone know what it is?
    
    Thanks
    Debbie
     

If something claims to implement DECnet phase 5 (by whatever the nom du jour
is) and it supports multiple adapters, then you should be able to expect it 
to pathsplit across adapters.  (In other words, if it doesn't you'd be 
entitled to a QAR...)

	paul

    Those are some pretty high performance expectations (800 Mb)...

    If the answer was yes, you'd then have to ask the next question:
    
    What is the overhead of running those protocols and will that overhead
    be significant enough such that the applpication becomes CPU bound?
    Don't forget the overhead of the "other" pieces of this application
    and anything else you might have running on these machines as well.
    
    							/Bill
    

    re: .4
    
      Agreed. I mentioned this to the customer, performance at the datalink
    level as opposed to performance at the application level. They are
    aware of these implications. And also expecting Alpha to perform as
    advertised, so being CPU-bound as not much of an issue. They are
    looking at implementing this application in the 1995-1999 timeframe, so
    we all know that anything could be possible, CPU-wise by then. I've
    also received a few comments about TCP/IP not being capable of those
    speeds, as it stands today. So all that will have to be taken into
    consideration by the customer. He was asking if it would be possible
    for them to build interface cards for Sonoma if we didn't have
    something they need, so I have a feeling that if they need to write
    their own protocol, it wouldn't be totally impossible!
    
    Debbie