[Search for users]
[Overall Top Noters]
[List of all Conferences]
[Download this site]
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.R | Title | User | Personal Name | Date | Lines |
---|
1435.1 | little bit more trace | CSC32::B_GRUBBS | | Wed Aug 31 1994 19:57 | 17 |
| 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.2 | anybody seen such a thing? | CSC32::B_GRUBBS | | Wed Sep 07 1994 14:46 | 1 |
|
|
1435.3 | tcp_output.o fixed it... | CSC32::B_GRUBBS | | Thu Sep 08 1994 15:00 | 7 |
|
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
|