[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

1435.0. "OSF, DEFTA, socket close starts looping" by CSC32::B_GRUBBS () Wed Aug 31 1994 19:21

    Customer sent me this email.  They are using DEFTAs, osf v2.0, 
    and I have already had them apply the if_fta.o and if_fta_data.c
    patches.  Basically it looks like they are able to hang the
    machines in some kind of cpu intensive looping tryig to close
    down a socket that has been opened across an FDDI link.
    
    
    Anybody seen anything like this before?
    
    --Bert Grubbs
      Colorado CSC
   
    ------------------------------------------------------------------------
    
    I applied the patch you sent me for the FDDI code, and I am still
    having the same problem. This problem only occurs under heavy network load.
    It has happened on connections between two Alphas and on connections 
    between RS/6000s and Alphas.  Here is some more detail:
    
    1. Two application programs are communicating over a socket. In the
    cases I have traced, both applications are running on AXP 300X workstations
    running OSF/2.0.  One application (running on babbage) connects to the 
    other (running on turing) and sends data as fast as it can for ten seconds,
    then closes the connection. The FDDI analyzer shows the data moving between
    the machines, but at the end of the connection the amount of the data on 
    the ring drops to about 350K bytes/sec and the number of packets on the 
    ring rises to about 8000 packets/sec.
    
    2. The two machines appear to be hung, I cannot telnet to them, and
    keyboard and mouse don't get a response. However, when I unplug one of the
    machines from the ring and put it right back on by pulling the connector 
    out of the concentror and putting it back in, the traffic on the LAN 
    stops and both machines work normally.
    
    3. The problem is more likely to occurr when the socket buffer size
    (SO_SNDBUF and SO_RCVBUF) is set to 8192.  It happens less often with 
    16384 socket buffers and has happened at least once with 32768 byte 
    socket buffers.
    
    
    4. I did a trace of the packets on the LAN, it looks like the end of
    the TCP handshake to close the connection, except these keep getting sent 
    over and over on the ring.
    
     Source     Dest    Seq #    ACK #  Flags
    -------  -------  -------  -------  -------
                         .
                         .
                         .
    
    turing  babbage  ...2001  ...0259  A=1,F=1
    turing  babbage  ...2001  ...0259  A=1,F=1
    babbage   turing  ...0259  ...2002  A=1
    babbage   turing  ...0259  ...2002  A=1
    
T.RTitleUserPersonal
Name
DateLines
1435.1little bit more traceCSC32::B_GRUBBSWed Aug 31 1994 19:5717
    here's a little bit longer trace of what they saw:
    
    
    Source    Dest      Seq#     Ack#     Flags
    --------  --------  -------  -------  ---------------
    babbage   turing    ...0259  ...2002  A=1
    babbage   turing    ...0259  ...2002  A=1
    turing    babbage   ...2001  ...0259  A=1,F=1
    turing    babbage   ...2001  ...0259  A=1,F=1
    babbage   turing    ...0259  ...2002  A=1
    babbage   turing    ...0259  ...2002  A=1
    turing    babbage   ...2001  ...0259  A=1,F=1
    turing    babbage   ...2001  ...0259  A=1,F=1
    .
    .
    .
    
1435.2anybody seen such a thing?CSC32::B_GRUBBSWed Sep 07 1994 14:461
    
1435.3tcp_output.o fixed it...CSC32::B_GRUBBSThu Sep 08 1994 15:007
    
    wasn't an fddi problem......fixed already with the tcp_output.o
    patch for osf v2.0 that can cause cpu intensive processes or
    hangs when the window size goes negative.
    
    
    --Bert