COPY FROM INTEGRITY PLATFORM TO ALPHA PLATFORM WORKS VERY SLOW

[Volvocars]

Hi,
If I want to copy files from an integrity node named NVK (RX2620) to an alpha node named NVI (DS20E), the copy operation of a file of 9593 bytes from NVK to NVI happens at a very slow speed : about 1000 blocks copied in 15 min. In the opposite direction from NVI TO NVK the copy happens instantly.

TCP VERSION ON THE ALPHA NODE NVI
TCPIP> SHO VERSION

HP TCP/IP Services for OpenVMS Alpha Version V5.5 - ECO 1 on a COMPAQ AlphaServer DS20E 666 MHz running OpenVMS V8.2
TCPIP>

TCP VERSION ON THE INTEGRITY NODE NVK
TCPIP> SHO VERSION

HP TCP/IP Services for OpenVMS Industry Standard 64 Version V5.5 - ECO 1 on an HP rx2620 (1.60GHz/3.0MB) running OpenVMS V8.2-1
TCPIP>

Both networkcards are configured as twisted pair and speed 100.

Via the mc lancp command I noticed that on the integrity machine NVK that collision packets are sent which is not happening on the alpha machine NVI.
mc lancp> sho dev eia0/count
LANCP> sho dev eia0/char/count

Device Counters EIA0:
Value Counter
----- -------
203619 Seconds since last zeroed
139799511 Bytes received
24651521 Bytes sent
952902 Packets received
69171 Packets sent
131987082 Multicast bytes received
4070900 Multicast bytes sent
901513 Multicast packets received
26530 Multicast packets sent
3 Unrecognized unicast destination packets 32389 Unrecognized multicast destination
packets
0 Unavailable station buffers
0 Unavailable user buffers
0 Alignment errors
...
6738 Initially deferred packets sent
277 Single collision packets sent
678 Multiple collision packets sent
0 Excessive collisions
3481 Late collisions (17-NOV-2006 05:43:28.00)
0 Collision detect check failures

What could be the course of that, can someone help me with this problem

Mario Dhaenens
Volvo Cars Gent
Mdhaene1@volvocars.com

[Karl Rohwedder]

The 1st thing to check is always speed and duplex setting of both the NICs and the associated switch ports. Then maybe trying another cable.

regards Kalle

[labadie_1]

Do you use Decnet IV, Decnet V, Tcpip ?

Your command is
copy/ftp ?

Are the 2 nodes in the same Decnet Area if you use Decnet ?
May be you do not go through the same routers when you go from NVI to NVK and from NVK to NVI ?

[Volker Halle · Accepted solution]

Mario,

'collision packets sent' does not mean, that 'collision packets' have been sent, this says that a network packet has been successfully sent, after single or multiple collisions have been seen WHILE trying to send the packet.

The fact that the NIC also saw 'Late collisions' seems to indicate some problem in the network configuration. A collision is only supposed to happen within a certain time slot after beginning the transmission of a packet.

Is the NIC connected to a switch port ? Is this switch port set to auto-negotiate ? Could there be a hdx/fdx mismatch ?

With the most recent NICs and OpenVMS versions, it is advisable to set both the NIC and the switch port to auto-negotiate. You can not change the setting at 'console level' on Itanium - auto-negotiate should be the default - but you could change the setting with LANCP DEFINE (or SET).

Volker.

[Peter Zeiszler]

mc lancp sho dev eia0/param

Check your settings for auto, speed, full duplex, etc.
Check with network admin for the settings on the switch. See if they are getting errors on that switch.

Make the settings either match or Auto negotiate on both sides. I personally have had issues letting both sides auto negotiate on alphas but don't have an integrity system yet.

Do these checks on both systems.

How are you doing the copy? Decnet? Ftp? Copy/FTP? RCP?

[rick jones]

Indeed, one of the indicators for autoneg on one side and hardcode on the other is for the side which was in autoneg to have late collisions - indicating it was in half-duplex and the switch was hardcoded to full-duplex. the full-duplex side likely is reporting FCS (CRC) errors

attached is some boilerplate on autonegotiation - not VMS specific

[Robert Gezelter]

Mario,

I concur with Kalle, Volker, Rick, and the others. I have seen this problem several times at various clients.

Late collisions, missed packets, and other similar symptoms are frequently the result of network misconfiguration (e.g., mis-matched full/half duplex, auto-negotiate) and other network misconfigurations.

You can confirm this with a network analyzer, the symptom is a timeout (lost packet) at the NSP (for DECnet) or TCP/IP layers (IP) followed by a retransmission. Since the timeouts for lost packets are on the order of seconds, the problem presents as a multiple order of magnitude reduction in network throughput.

A check of your network is in order.

- Bob Gezelter, http://www.rlgsc.com

[Volvocars]

Hello guys,

I found the problem, the NIC card of the integrity platform had the Auto-negotiation enabled. Via mc lancp, I disabled the Auto-negotiation. Then the copie operation worked at the expected speed. Thanks for you help

[comarow]

Obviously, from the start, this seemed to be a network problem. However, I'm surprised that it worked faster in one direction than the other.

Any idea why that should be?

[Richard Brodie_1]

"Obviously, from the start, this seemed to be a network problem. However, I'm surprised that it worked faster in one direction than the other.

Any idea why that should be?"

One of the things that gives the Ethernet CSMA/CD algorithm its efficiency, is that (in normal operation) the contention only takes place in the first 64 bytes of each packet. If nothing goes wrong then, you should have the rest of the 1500 bytes free sailing. That's why, contrary to popular belief, collisions rarely consume a significant percentage of line utilization. Also one of the reasons why "late collisions" are a really bad thing.

Now, suppose you are in the middle of a large packet on a misconfigured link. If the packet is being sent from the FD end, the HD end will sense carrier and hold off. If the packet is being sent from the HD end, there is no such guarantee. If I'm happy to interrupt you but not vice versa, it's going to be me that is able to get a message across.

So, asymmetric performance, coupled with late collisions, is pretty typical of this particular problem.

[Robert Gezelter]

Bob,

I concur with Richard.

When one goes down to the actual "physics" of CSMA/CD, and a blackboard, the symptoms are not as bizarre as would appear at first glance. This is particularly true when the underlying rules of IEEE 802.3 are violated. In particular, IEEE 802.3 networks rely VERY heavily on the presumption that a packet has arrived safely if not error is immediately detected. An unreported error at the LAN layer must be detected at the IP layer, which has a far larger time tolerance for error conditions.

The half/full duplex asymetry is classic. One side of the connection does not care, and the other side of the connection cares very much if traffic is already present, thus the problem.

- Bob Gezelter, http://www.rlgsc.com