[Search for users]
[Overall Top Noters]
[List of all Conferences]
[Download this site]
Title: | Alpha Workstation Conference |
Notice: | See note 1.* for conference notices |
Moderator: | WRKSYS::HOUSE |
|
Created: | Wed Sep 07 1994 |
Last Modified: | Fri Jun 06 1997 |
Last Successful Update: | Fri Jun 06 1997 |
Number of topics: | 1996 |
Total number of notes: | 9122 |
1829.0. "Interactive network response 'lumpy'" by IOSG::MARSHALL () Sun Feb 02 1997 09:32
Alphastation 255, Digital Unix V4.0A, firmware CD V3.8
Bit of a hard-to-track-down network problem.
Basically, interactive response time is very variable. For example
- rlogin to another machine (Unix or VMS)
- run up LSE and move around, type stuff, etc
Some of the time the screen updates match what I type 'instantaneously',
sometimes there can be a delay of up to ten seconds before the screen reflects
what I've typed.
During that time I can do other things locally, so my Unix machine isn't
hanging, and other people can do things quite happily on the remote machine, so
that isn't hanging either. The behaviour is the same regardless of which remote
machine I use.
It isn't network congestion. We've checked that out and the network is very
lightly loaded, and no-one else has this problem.
It isn't the network configuration. The problem has existed since this AS255
was first plugged into the net; the previous machine plugged into the same bit
of thinwire didn't have the problem.
Since then, the thinwire has been replaced with UTP, and that made no
difference. The UTP wire from this AS255 has been moved to a different
repeater, which also makes no difference. Other people on the same repeaters
have no problems.
All of which is making the problem look very much like it's in the AS255.
Oh, also, the AS255's motherboard (which contains the network hardware, for
those not familiar with this machine) has been replaced for other reasons, and
that made no difference, so it's not mal-functioning hardware.
However, bulk network operations seem to run quickly and smoothly; 'cat'ting or
'type'ing large files from a remote machine works fine. It's only small
"interactive" packets that seem to get held up.
Is there something I can run on the AS255 to monitor what it's doing with the
net to figure out what's causing the delays? Is there some tuning that can be
done to improve performance for small packets (nb before anyone says rtfm, I
would if I had one!).
Does anyone have any ideas at all what is causing this?
Many thanks,
Scott
[x-posted in turris::digital_unix]
T.R | Title | User | Personal Name | Date | Lines |
---|
1829.1 | Problem in .0 seems to be AS255-specific | IOSG::MARSHALL | | Wed Apr 16 1997 11:56 | 33 |
| The problem in .0 persists; since posting that note I've been chasing it up in
the UNIX conf, and also with our local network specialists.
The current situation is this:
There is absolutely nothing wrong with the rest of the network.
It isn't a complete network "hang"; I can have two windows with remote sessions
(to the same remote machine) and one can hang while the other is fine; then a
few seconds later the situation could reverse.
Netstat (the UNIX command for displaying network statistics) shows a higher than
expected number of error packets, and indeed sometimes characters seem to be
lost.
The problem is worse when network traffic increases, but the network is nowhere
near saturated, and the problem persists even when the network is otherwise
quiescent.
We notice similar symptoms on all AS255s, but not on other machines (this isn't
conclusive yet, but is a definite trend). Related to this it could be an
introduced bug in UNIX V4.0; I will pursue that line in the UNIX conf.
The last point is why I've come back to this conference. Whatever the problem
is, it seems specific to AS255s (or possibly other new machines; it's just that
all our recent purchases have been 255s).
What could be 'wrong' with AS255s to cause this behaviour? Given that it seems
to be hardware-related (although not a broken component - see .0), what can we
do to fix it, or at least identify the cause?
Thanks,
Scott Marshall
|
1829.2 | guess | WRKSYS::DISCHLER | I don't wanna wait in vain | Thu Apr 24 1997 09:29 | 9 |
| This is a guess. A while back, the Ethernet MAU cards (one
of the designs) had chassis ground and Enet gnd tied together.
This caused some errors and re-tries. - and in some cases
all-out failure. The newer MAU cards have the gnds separated.
The new ones were phased in.
Just a guess; This might not at all be the source of your
problem.
RJD
|