| An interesting problem. Some things worth considering:
- Check the error counters on both machines. If the problem is a
degraded link, then the counters should reflect this.
- What machines are in between the two nodes? Are any of these
machines routers or bridges? Is it possible that the asymmetric data
throughput is being caused there?
- Any duplicate LAN, DECnet, or TCP addresses? Duplicate addresses
often cause weird problems like this.
good luck,
bill
|
| It isn't farfetched - I was involved with a similar problem recently.
In that case the complaint was that a transfer from X to Y took
milliseconds, and the transfer from Y to X took several seconds.
The network looked like this:
+-----------------------------------------+
| |
+---X--Y--1--2--3--4--5--6--7--8--9-------+
As Bill M suggested, we first searched the PHY LEM and LEM Reject
counters, for each node in the path (about 60 ports in all) and all
looked good. We then looked at all of the MAC Lost
and FCS Error counts, and all looked good. It turned out that one of
the stations between Y and X was clobbering the packet, but not ticking
its counters. We eventually isolated it by having Y transmit first to
1, then 2 etc, until,the errors began - then we removed the suspect
node, and all was well.
|
| This is the FDDI conference but it 'sounds like' you are talking about
an Ethernet link. If this were an FDDI network I'd be looking for some
sort of DECnet parameter problem. Like pipline or packet size.
If, in fact, it is an ethernet link then the transmit and recieve paths
are somewhat independent.So a transmission path problem is more of a
possibility.
At any rate there used to be a VMS utility called DTS/DTR to allow
tests of varying packet sizes. If the two systems have this utility it
could turn out to be a worthwhile exercise to see if you can reproduce
the problem with this test. Start with small transfers (say 100 bytes)
and work your way up to see if you can reproduce it.
Jim
|