[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference 7.286::fddi

Title:FDDI - The Next Generation
Moderator:NETCAD::STEFANI
Created:Thu Apr 27 1989
Last Modified:Thu Jun 05 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:2259
Total number of notes:8590

177.0. "TCP throughput over FDDI" by OTOA01::RUBINGER (John - Atlantic Canada DWT) Thu Nov 29 1990 17:48

    (crossposted in the DWT and Internet Notesfiles)
    
    Has anybody seen any benchmarks that show throughput at the TCP level
    through the DECstation 5000's FDDI controller?
    
    My customer wants to write an application that accepts a multiple
    streams of TCP packets from networked data acquisition devices on an 
    FDDI ring, merges them into a single stream and puts them back on the
    ring for archiving by a networked tape device.
    
    The customer wants to know how many acqusition devices he can support
    before he chokes the DECstation.  He wants to know what the throughput
    from the merge process to and from the FDDI controller is.
    
    Any guesses as to how much load this type of activity would place on
    the O/S?
    
    As always, any help is appreciated.
    
    Regards,
    John
    
T.RTitleUserPersonal
Name
DateLines
177.1Your results WILL varyENUF::CAUDILLKelly-T&N Mkg Tech Supp - 264-3320Wed Dec 12 1990 19:1719
    I haven't seen any real benchmarks, but I seem to remember seeing a
    demo somewhere which used DECstation 5000s to send data over the FDDI. 
    
    As I recall, in this demo, the fastest one DS5000 could send TCP
    packets to another DS5000 over FDDI was around 18mega-bits-per-second
    (that's only counting the user data).  This was with max sized packets. 
    With smaller packets, the throughput would reduce.  The main
    performance factor is packets-per-second rather than bits-per-second.
    
    With UDP, however, the demo could get up to 33mega-bits-per-second.
    
    The difference between the throughput with UDP versus TCP was due to
    the processing overhead in the TCP code (versus the UDP code) in ULTRIX.
    Running TCP at 18meg took 100% of the DS5000 CPU while the FDDI
    controller and the bus were not even breathing hard.
    
    Of course this was just a demo, not a benchmark.  The demo performed no
    processing on the data which it sent or received - the sender just sent
    a preallocated buffer filled with x00 and receiver through the data away.