Conference 7.286::fddi

>    I have a customer who is accessing the FDDI via the DLI interface.
>    At bandwidth rates above 65 Mbits/sec, a receiver starts losing packets.
    
>    Is this to be expected? 

Probably. 
 
>    Other protocols (like TCP) seem to get close to 100 Mbits/sec without
>    loss or retransmits. How do non-DLI based protocols do it?

They use something called flow-control.  They also keep receives pending
on the socket.
   
>    When the receiver gets a sigio, it does a select to find out which file
>    descriptor is read ready, and then it performs non-blocking reads utill
>    no more data is available.

This is part of the problem.  The latency (the amount of time between
when the packet is put on the socket receive queue and the time the packet 
is read off of it) will be very high since the signal delivery and select
are very expensive system calls.  The CPU that could be used to reading
data is being consumed trying to figure out which socket to read.

    Thanks for the quick response.
    
    What does it mean to "keep receives pending on the socket"?
    
    P.S.
    I will try a blocking read approach on the receiver to see if that
    helps.  This may become a viable approach in the future when a
    multithreaded compiler becomes available.  I'll let you know how the 
    blocking read performed in comparison to the non-blocking read.
    
    Thanks,
    
    Mike Thomas
     

that means blocking reads

    I found out there was a bug in the VADS compiler related to sigio
    processing.  This problem was fixed and so I ran some speed trials on
    the 2100 to see what clean (non-packet droppin') read rates could be
    obtained.
    
    NON-BLOCKING READS:
    
    Using async reading, the test driver could only read cleanly at
    75Mbits/s.  At higher bandwidth utilization rates, packet loss was
    experienced.  The sender used 25% of the CPU over a two minute run. 
    One percent of the time it was executing user code and 24% of the time
    it was executing system code (e.g. the DLI device driver which does the
    FDDI I/O.)  The receiver used 67% of the CPU over a one minute run. 23%
    of the time it was executing user code and 44% of the time it was
    executing system code.  CPU utilization appeared linier as a function
    of badnwidth utilization.  Rule of thumb: 1% CPU used to send each
    3 Mbits/s and 1% of CPU used to receive each 1 Mbits/s.  (Max length
    packets were sent.)
    
    
    BLOCKING-READS:
    
    I RERAN THE TESTS WITH THE NETWORK INTERFACE CODE MODIFIED TO PERFORM
    BLOCKING READS AND COMPARED RESULTS WITH THE NON-BLOCKING FLAVOR
    INTERFACE.
    
    The blocking read driver was able to read in execc of 99 Mbits/s!  The
    receiver used 23% of the CPU over a one minute run. 2% of the time it
    was executing user code and 21% of the time it was executing system
    code.
    
    The customer can probably live with the 75% limitation until the
    multithreaded version of the VADS Ada compiler is available and then
    can switch to blocking reads.
    
    Many thanks for your help Matt.  Your analysis and insight into the
    problem were flawless.  When we saw the non-blocking read packet loss,
    we wern't sure whether it was a problem we could fix or just the nature
    of the non-blocking read itself.  Bottom line is that you need to do
    blocking reads via DLI interface to acheive receive bandwidths over
    75%.
    
    Greatfully yours,
    
      Mike Thomas