Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 7 Aug 1998 13:18:26 -0700 (PDT)
From:      Doug White <dwhite@resnet.uoregon.edu>
To:        "sysadmin@mfn.org" <sysadmin@mfn.org>
Cc:        "'freebsd-questions@freebsd.org'" <freebsd-questions@FreeBSD.ORG>
Subject:   Re: FTP Symptom of Network Problem...
Message-ID:  <Pine.BSF.4.00.9808071315030.15104-100000@resnet.uoregon.edu>
In-Reply-To: <01BDC14B.144DE880@noc.mfn.org>

next in thread | previous in thread | raw e-mail | index | archive | help

On Thu, 6 Aug 1998, sysadmin@mfn.org wrote:

> Greetings...
> 
> 	Before I go any further, here's the map:
[ bunch of machines connected to hub, monitor is chained off of coax ]

> I was getting calls from angry users on machines in this
> segment, all complaining (*loudly*) about "lag that often
> runs over 30 seconds".

Hm...

> (3) In an attempt to get a better look at things, I took
> a machine from another segment, and put it on here.  The
> plan was for this machine to be a full-time monitor (as
> the name above shows).  Using "monitor", I was finally 
> able to experience problems myself, although only in FTP.
> When logged in to "monitor", FTP speeds in retrieving files
> from "server" runs under 10kbps, when it runs at all.  Often
> it will time out and be "reset by peer".  It's not that bad
> packets are being sent and resent: there is a packet sent,
> and then a *long* pause, and then another, and the cycle
> repeats.  

If you can reliably reproduce this run a tcpdump while running the FTP and
see what comes up.

> (4) I can log in to any workstation and ftp from "monitor"
> at full speed (~750kbps).  I can log in to "monitor" and 
> ftp from any workstation at full speed.  As far as I can
> tell (user complaints aside), I can login to any workstation
> ("A" - "L") and get files full speed from "server", and 
> vice-versa.  But as long as I am logged in to "monitor"
> and trying to get files from "server", I'm in deep trouble.
> The *only* thing I see "odd" here is a collision rate of 
> about 10% on "monitor". 

Considering that monitor is chained off the coax link and it's getting
collisions, and the rest are on 10BaseT, I'd immediately suspect the coax
connection.  If there's a flakey device on the chain, incorrect
termination, or someone is taking devices off the network you might see
the problem for traffic going over that wire.  Perhaps the uplink cable
from the hub to the router is flakey?

> (5) In trying to isolate "monitor"'s problem, I have:
>  > Replaced cabling for both "monitor" and "server"
>  > Replaced NIC's for both "monitor" and "server"
>  > Reloaded the OS for both "M" and "S"
>  > Both raised and lowered "MAXUSERS" for "server"
>  > Placed another machine in "monitor's" position

So, are you saying it's specific to monitor, independent of the link type?

> I am completely out of ideas here.  I am also completely
> out of patience  :(   I have a dozen angry users that I
> can't placate because I can't even verify their problem
> (other than on "monitor"), and I have what looks like a 
> physically impossible interaction between "monitor" and
> "server"...
> 
> Anyone have *any* (no matter _how_ off the wall) ideas?

tcp_extensions?  Should I assume that server is a freebsd box?

Doug White                              | University of Oregon  
Internet:  dwhite@resnet.uoregon.edu    | Residence Networking Assistant
http://gladstone.uoregon.edu/~dwhite    | Computer Science Major


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-questions" in the body of the message



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.00.9808071315030.15104-100000>