| We are having a problem with something in a DEChub900 which is evading
isolation.
The DEChub900 is mounted in a rack with an Alphastation 400 4/233. The
Alpha station is connected to the hub via a DECrepeater 90C (thinwire
repeater). It is the only device on the repeater. Also in the hub is a
DECrepeater 90FS (DEFMI) which has 2 fibre pairs and a an AUI. There are
thress fibres that go out of this repeater, two ont he fibre connectors and
the third via a FOT on the AUI. In addition there is a DECbrouter90T1
connected to a 512Kbps serial link to another site which is similar except
that there is no thinwire repeater nd the alpha server is a 2100/MP500/275.
It is connected to the hub via fibre.
The problem:
We first noticed the problem when the 400 4/233 NFS mounted a filesystem on
the 2100. If you did anything that was largish in transfer size, the NSF
client would inidcate the NFS server was not responding. But if you kept
the dta size small it was fine. As a simple example, if you 'ls' the root
of the NFS mount point (about 17 files), response is instant. But if you go
into a subdirectory with about 700 files and 'ls' it will take over 5
minutes to get the listing, with several NFS server not responding messages
. I don;t think you could call a directory listing of 800 files a heavy
duty task.
We also came up with another test.
If you ping the 2100 from the 400 all is OK. If you raise the packet size
to 7000 bytes say, you will start to lose packets, i.e. sequence numbers a
re skipped. It varies but upto 20 packets are lost before one is echoed.
BTW: The network is dead idle and a similar test from the 2100 to another
2100 on the net on a 128Kbps line, via two routers passes both tests
without fault.
Solution:
We can make the problem go away. If we connect the 400 to fibre (via a FOT,
the 400 hs a DE205 in it), the problem disappears completely.
If we use another machine (a 200 2/233) on the Thinwire, the problem comes
back. Put the new machine on fibre, it goes away. But if you ping the 400
from the 200 there appears to be no problem.
By now it sounds pretty clear that the thinwire repeater is at fault except
for the last test which would seem to indicate it's OK.
We got MCS to replace the thinwire repeater and the problem is still there,
so it's probably not the repeater.
Any suggestions would be most welcome!!!!
/richard
|