Operating System - OpenVMS
1752727 Members
5788 Online
108789 Solutions
New Discussion юеВ

Re: ftp put file problem on OpenVMS

 
цЭОф┐Кш│в
Occasional Advisor

ftp put file problem on OpenVMS

Dear All
I found some "ftp put" problem on our Alpha server

TCPIP> sh ver

HP TCP/IP Services for OpenVMS Alpha Version V5.4 - ECO 6
on a AlphaServer DS20 500 MHz running OpenVMS V7.3-2

I put file to myself
$ftp test07
$put test.txt
first the speed is very slow 33.98/s but after 2 mins the speed is 2000/s
but when I use ftp get the speed is always 4000/s

can any one give me suggest
Thanks a lot
12 REPLIES 12
Jur van der Burg
Respected Contributor

Re: ftp put file problem on OpenVMS

You want to define the logical names tcpip$ftp_file_alq and tcpip$ftp_file_deq on the server. The defaults are way too low, causing excessive overhead when the file is extended.

Here's the doc:

http://h71000.www7.hp.com/doc/83final/6526/6526pro_041.html


Jur.
Hoff
Honored Contributor

Re: ftp put file problem on OpenVMS

4000/s? What unit? What NIC?

In addition to the RMS extent sizes (a very good initial suspect here), also confirm the process quotas in the target ftp environment are sufficient. If this box has been around for a while, you may well have low quotas there.

Check for disk fragmentation in the target environment, too.

And irrespective to the issues around ftp performance, do seriously consider switching to the DCL syntax when working with DCL and ftp:

COPY/FTP

such as the following example

COPY/FTP/ASCII test.txt ftp.example.com"user pwd"::test.txt

This command syntax is easier to work with, and you can perform DCL symbol substitution and DCL command processing directly within the command. And (when scripting ftp) you don't need a temporary file, either.

John Gillings
Honored Contributor

Re: ftp put file problem on OpenVMS

Long shot, but always worth checking. Please make sure all your network adapters and switch ports are set to AUTONEGOTIATE.

Or, at the very least make sure all pairs of ports are set identically (that is, if the host adapter is set to 100/full, make sure the corresponding switch port is set the same)
A crucible of informative mistakes
цЭОф┐Кш│в
Occasional Advisor

Re: ftp put file problem on OpenVMS

Hi All

1.The switch and lancp config OK!
2.4000kb/s means the speed when I press the CTRL+T
07::_TNA6: 11:50:39 TCPIP$FTP CPU=00:00:14.96 PF=2453 IO=62664 MEM=346
PUT (IMAGE) 559042560 bytes 00:04:56.54 elapsed (1840.98 KB/S)
Local: DISK803:[MIS.JACKYLEE]TEST.TXT;8
Remote: TEST.TXT
3.I found when I use ftp put file to OS disk everything is OK! but when i put file to other disk ftp speed is very slow,and disk hung

Please give me some suggestion
Thanks a lot
Hein van den Heuvel
Honored Contributor

Re: ftp put file problem on OpenVMS

Well, it may be as simple as free space FRAGMENTATION on the target disk.

Download DFU from www.digiater.nl.
REPORT on both disks.

FTP speed to similar disks should have similar performance. If not, there is an unrecognized difference. Assuming similar configuration, the first suspect is (IMHO) fragmentation. But us the system disk indeed similar to the other disk? Both on SAN nor neither on san?

Hein.

цЭОф┐Кш│в
Occasional Advisor

Re: ftp put file problem on OpenVMS

Dear All
I solve this situation
I check the device type and find high-water marking
$sh dev disk300/full
Volume Status: ODS-2, subject to mount verification, file high-water marking,
write-back caching enabled.

and init the disk
$dismount disk300
$init/nohighwater dkb300: disk300
$mount/system dkb300: disk300

$sh dev disk300/full
Volume Status: ODS-2, subject to mount verification, write-back caching
enabled.

Then I test ftp PUT file everything is fine!
John Gillings
Honored Contributor

Re: ftp put file problem on OpenVMS

>$dismount disk300
>$init/nohighwater dkb300: disk300
>$mount/system dkb300: disk300

OUCH!! You mean you wiped the whole disk just to turn off highwater marking?? Talk about a big hammer.

You can turn highwater marking on or off at any time without dismounting, or affecting your data in any way. It's safe and instant.

Next time try:

$ SET VOLUME/NOHIGHWATER_MARKNIG DKB300

or to turn it on again:

$ SET VOLUME/HIGHWATER_MARKING DKB300

I'd recommend you do a sanity check. Try your test again, with highwater on and off. My guess is you WON'T see a huge difference. The real issue was probably something completely different, that the INIT fixed (for example, fragmentation).

It's important to check this, just to make sure you don't go away with the impression that highwater marking could cause such a large performance hit.
A crucible of informative mistakes
цЭОф┐Кш│в
Occasional Advisor

Re: ftp put file problem on OpenVMS

Dear John

Thank you very much
next time I will use set volume command

This machine is a test environment so I can do any test on this machine.
I try DEFRAGMENT command first but still have ftp put problem.

Hoff
Honored Contributor

Re: ftp put file problem on OpenVMS

I will assume you are performing exactly the same FTP command for the get and the put, and the only difference is with the specific default target disk, and whether the operation is a get or a put. (This to ensure the local box is not contributing to the ftp speed differences here, whether due to contention, fragmentation or caching..)

> but when i put file to other disk ftp speed is very slow,and disk hung

A solidly hung disk? That's definitely both interesting and quite potentially relevant here, and usually not goodness.

Look for disk errors.

Look for a bad disk.

Look for conflicting activity on the disk and on the bus.

Look for SCSI configuration or termination errors.

Look for differences in default allocation and default extent sizes as established on the drives.

Look for speed differences among the drives.

The disk settings usually provided by the default INITIALIZE command are somewhere between bad and awful, too. Cluster size and particularly extent size are two that can be central here.

This is ancient and slow gear and accordingly ill-suited for any sort of serious performance and tuning work. I'd expect the disks are of a similar and old and slow vintage; not the best for speed. Replace the gear.

Beyond discussions of disks (which do appear involved here) ftp itself has various issues with network performance and firewalls and related. OpenVMS ftp isn't itself particularly fast, and the way that ftp works in general does not scale well nor operate well with modern networks. Here's some old reading on this topic:
http://h71000.www7.hp.com/wizard/wiz_5632.html