topic Re: ftp problem in OpenVMS V7.2 in Operating System - OpenVMS

ftp problem in OpenVMS V7.2

Glenn Joseph Andal — Thu, 17 Mar 2005 05:40:39 GMT

We are currently experiencing ftp slowdown on our newly implemented system. We've already checked configuration on the network layout(layer3 switches, routers, etc). That is why we came up with isolating the network interface adapter configuration on the compaq server. Please provide us procedure/checklist on how we can start the troubleshooting.

thanks.

Otep

Re: ftp problem in OpenVMS V7.2

Willem Grooters — Thu, 17 Mar 2005 05:45:28 GMT

First thing you _should_ avoid on the VMS side is auto-negotiate. It's a notoirious source of trouble. Set both connecting sides - VMS box and switch - to a fixed speed. You could try to use half duplex in stead of full duplex.

Re: ftp problem in OpenVMS V7.2

Ian Miller. — Thu, 17 Mar 2005 05:49:29 GMT

is the problem confined to ftp or does it apply to other protcols also?

Re: ftp problem in OpenVMS V7.2

Glenn Joseph Andal — Thu, 17 Mar 2005 05:58:43 GMT

Hi Williem, How about servers connecting to that host. do i have to change it also? as well as other hosts connected to that routers and switches?

Hi Ian, that is for ftp only. push and pull scenarios.

thanks

Re: ftp problem in OpenVMS V7.2

Glenn Joseph Andal — Thu, 17 Mar 2005 06:09:34 GMT

Please see output generated when doing our testing.

ftp> put SMAD11-0117.FCDR;1 test1
200 PORT command successful.
150 Opening data connection for SMSC_TCDR:[BILLING]test1.; (9.9.8.34,52603)
226 Transfer complete.
5179420 bytes sent in 21.02 seconds (240.64 Kbytes/s)
ftp> get test1 test1
200 PORT command successful.
150 Opening data connection for SMSC_TCDR:[BILLING]TEST1.;2 (9.9.8.34,52860)
226 Transfer complete.
5179420 bytes received in 348.53 seconds (14.51 Kbytes/s)

Re: ftp problem in OpenVMS V7.2

Karl Rohwedder — Thu, 17 Mar 2005 06:15:22 GMT

- regarding autonegotiate:
this applies only the VMS systems port

- regarding FTP:
are both directions slow or just writing?
If writing is slow, try to increase the Extendsize by which files are extended
(set rms/extend).

Then there is the famous TCPIP SET PROT TCP /NODEALY.

And last not least try increasing the TCP buffer spaces with SYSCONFIG (sysconfig -r inet tcp_sendspace=1048576 tcp_recvspace=1048576).

Be sure to have read the tuning manual, found under http://h71000.www7.hp.com/doc/732final/documentation/pdf/aa-rn1vb-te.pdf

Re: ftp problem in OpenVMS V7.2

Willem Grooters — Thu, 17 Mar 2005 06:50:25 GMT

Just the link betwen the VMS box and the nearest switch (the other side of the cable) need to be set fixed speed and duplexity. The rest should not matter.
(Personnaly I fail to understand why a server would need "auto-negotiate". These machines tend to located rather stablely in the network and don't hop from one location to another....)

Re: ftp problem in OpenVMS V7.2

Robert Gezelter — Thu, 17 Mar 2005 09:13:23 GMT

Willem,

With all due respect, I must differ with a part of your Mar 17, 2005 10:45:28 GMT.

While Auto-negotiate is well-known to cause problems, I do not remember any problems with Full Duplex.

The problems that I do remember where AutoNegotiation problems, where one side selected Full Duplex and the other went Half Duplex.

The best way to deal with a slowdown, is to analyze the traffic between the nodes, using an analyzer. Then work back to fix the actual symptom. While it is possible to fix things by repeated experimentation, it is a surer long term solution.

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

Re: ftp problem in OpenVMS V7.2

Wim Van den Wyngaert — Thu, 17 Mar 2005 11:34:59 GMT

Check what LAN settings you received with
mc lancp show dev/char.
Compare this with what the network team configured.

The put goes acceptable (240K/sec) and the get is slow (14K/sec).
This makes me believe that VMS is OK but the other side of the FTP has problems (or whatever that is in between).

Full duplex problems means that you generate errors on VMS when trying to put packets on the cable. When you put, it is the VMS side that is putting the packets on the network. When you get, it is the other side that is putting the packets on the network.

Re: ftp problem in OpenVMS V7.2

Robert Gezelter — Thu, 17 Mar 2005 11:44:26 GMT

Wim,

Actually, the effects of Full/Half Duplex mismatch vary wildly depending upon which nodes's messages get lost during the time window.

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

Re: ftp problem in OpenVMS V7.2

Wim Van den Wyngaert — Thu, 17 Mar 2005 13:24:57 GMT

Bob,

You might be right. I've already seen very strange behaviours.

In any case, you should most probably see collision (probably late) on the network interface. mc ncl sho csm stat * all (or use lancp or sda) and check the counters.

Wim

Re: ftp problem in OpenVMS V7.2

John Gillings — Thu, 17 Mar 2005 20:02:35 GMT

Re: Willem,

>First thing you _should_ avoid on the
>VMS side is auto-negotiate. It's a
>notoirious source of trouble

I have to disagree with this.

It's much better to use AUTONEGOTIATE on your OpenVMS systems. Most switches and hubs default to AUTO. Some of the cheaper ones cannot be configured otherwise. Pick a random port out there and odds are it will want to negotiate, so your systems should go with the majority. The protocol works, so you're better off using it.

The trouble comes when OpenVMS managers specify a fixed speed and the hub or switch it's connected to tries to negotiate. The protocol doesn't understand fixed speed ports, and can configure a duplex mismatch.
(one might argue that this is a failing of the negotiation protocol, but that's not something we're going to be able to change).

As of V8.2 (and recent LAN patches on older versions), OpenVMS will detect and report duplex mismatches on the console. Short term fix is to reset the local port using LANCP, but the long term fix is to enable autonegotiate at the console.

Everything is much simpler if you can forget about trying to make sure a particular cable needs to be plugged into a particular socket. Setting *everything* to autonegotiate makes that happen, so that's the current recommendation from OpenVMS Engineering and HP Customer Support.

Although I agree to some extent with your comment about servers being fixed, so why let them negotiate, the reality is the rest of the world expects autonegotiation, so we're better off complying than standing on principle. It also gives you the flexibility of changing your hub or switch technology without having to worry about configuring it.

Re: ftp problem in OpenVMS V7.2

Glenn Joseph Andal — Fri, 18 Mar 2005 00:39:23 GMT

Thank you Guys for you helpful and fruitful support. Our vendor already released their findings/suspected cause of the problem. Kindly provide me information if anyone already encountered this "Base on the test results and on the initial findings slow due to the limitation of "Protocol Stack - The term stack refers to the actual software that processes the protocols" . Currently servers is generating an average of 1,700 text Files per day (at a size of 5MB per file). Their estimate is it will take 337 Hrs or 14 days to transfer all of the 1,700 files with actual size of 8500MB (8.5GB) at a rate of 7Kbytes/sec."

Hope someone can help us on this. thanks again

Re: ftp problem in OpenVMS V7.2

Ian Miller. — Fri, 18 Mar 2005 04:37:15 GMT

I think hp know that the performance of the current ftp implementation is not as good as it good be :-)

Could you use HGFTP?
ftp://ftp.process.com/vms-freeware/fileserv/hgftp.zip

Re: ftp problem in OpenVMS V7.2

Robert Gezelter — Fri, 18 Mar 2005 06:37:09 GMT

Glenn,

7K a second is severly low. I strongly suspect that the problem is NOT the software on the OpenVMS side.

When getting an answer of that type, it is important to do a check on the reasonableness of the answer.

A suggestion: Connect the OpenVMS system standalone to another system, a notebook (laptop) computer with a reversed (null modem) RJ45 cable. Then do FTP operations in both directions. If, as I suspect, the problem is not on the VMS side, you will see substantially higher bandwidth.

In that case, the problem is not directly the protocol stack, but either a setting somewhere or a backbone problem. I have dealt with these problems many times, and they are almost always solveable (just dealt with such a situation the other week with KERMIT over LAT servers). [smile] When necessary, I have had to go into the field and troubleshoot the problem by decoding packets, but it is always solvable.

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

Re: ftp problem in OpenVMS V7.2

Jan van den Ende — Fri, 18 Mar 2005 09:45:54 GMT

Glenn,

OT, but from your profile:
"I have assigned points to 9 of 43 responses to my questions. "

See:

http://forums1.itrc.hp.com/service/forums/pageList.do?userId=CA949978&listType=unassigned&forumId=1

some of those are already rather old.

-- maybe you can find some time to fixe up some loose ends? Even if you do think an answer deserves no points, then assigning 0 points will remove the "unassigned" flag.

Proost.

Have one on me.

Jan

Re: ftp problem in OpenVMS V7.2

Robert Gezelter — Fri, 18 Mar 2005 10:37:26 GMT

Otep,

A footnote to my posting from earlier this morning.

7Kbytes/second is roughly equal to 56Kbits/second, which is roughly 0.5% of a first generation 10Mbit/second IEEE 802.3 (Ethernet) network. It is less than 0.05% of a 100Mbit/second network.

Unless you have a vey slow link (say a 56Kbit/second landline), this is an unreasonable level of network performance. I routinely do 100Mbyte transfers over a 10Mbps network between OpenVMS nodes in far less time (using various versions of HP TCP/IP, Multinet, TCPware, and DECnet).

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