1822469 Members
2404 Online
109642 Solutions
New Discussion юеВ

Slow FTP transfers

 
SOLVED
Go to solution
SmokeyBob
Established Member

Slow FTP transfers

I am trying to FTP transfer an Oracle database export of 1.4GB and transfer speed stays around 9k.
The server is running DIGITAL TCP/IP Services for OpenVMS Alpha Version V5.0A on a AlphaServer ES40 running OpenVMS V7.1-2.
I am connected on an internal Ethernet network.
I can make multiple ftp connections to the server and they all run at the same speed, so I assume it is being limited on OpenVMS's side.
I have googled myself silly and cannot find documentation on checking or setting ftp connection speed limits.
I am sure there are other ways to accomplish this, and am open to suggestions. This seemed like a simple way to get a one time transfer from the system, but it takes several days to download and the server keeps disconnecting from the FTP client after several hours and then the transfer starts over. Appreciate any help I could get.

Thanks, Bob

7 REPLIES 7
Steven Schweda
Honored Contributor

Re: Slow FTP transfers

> I am trying to FTP transfer an Oracle database export of 1.4GB and
> transfer speed stays around 9k.

   So, that's a single (binary) file?  "9k" _what_?  Bits or bytes?  Per
second?  Measured how?  "Transfer" to/from what to what?  How, exactly?
Which system is the FTP client, and which the FTP server?  Actual
command(s)?

> The server is running DIGITAL TCP/IP Services for OpenVMS Alpha
> Version V5.0A on a AlphaServer ES40 running OpenVMS V7.1-2.

   So, old.  Not necessarily a problem.

> I am connected on an internal Ethernet network.

   Interface speed?

      SHOW DEVICE /FULL ethernet_device

   I'd guess that "ethernet_device" would be something like EIA0 or EWA0.
For hints:

      SHOW DEVICE E

> [...] so I assume it is being limited on OpenVMS's side.

   Or the network connection to it?  Have you looked at the hardware?
What does the relevant hub/switch/router say?

> [...] cannot find documentation on checking or setting ftp connection
> speed limits.

   I can't recall ever seeing such a thing.

> [...] the server keeps disconnecting from the FTP client after several
> hours and then the transfer starts over.

   "disconnecting"?  Actual error message(s)?  "then the transfer starts
over"?  Who does that?

> Appreciate any help I could get.

   You first?  As usual, showing actual actions (commands) with their
actual results (error messages, ...) can be more helpful than vague
descriptions or interpretations.  Copy+paste is your friend.

SmokeyBob
Established Member

Re: Slow FTP transfers

Hi Steven,

Yes, it's a single binary file (1,406,042,112 bytes) created using Oracle's exp command. It's currently transferring at about 9.8 KiB/s and has been running for 26h:11m with no disconnections so far (fingers crossed). It still estimates 11h:49m remaining.

I increased the connection timeout in FileZilla from 30 seconds to 300 seconds. When previous disconnections occurred, the display simply showed "Connection closed by server." Filezilla would restart the transfer, I belive I set it to retry 20 times.

The file is being transferred to a Windows laptop running FileZilla Client. It's connected to the OpenVMS server using its IP address and SYSTEM credentials.

BRISTOL $ sh dev /full eia

Device EIA0:, device type i82559, is online, network device, device is a
template only.

Error count 0 Operations completed 0
Owner process "" Owner UIC [SYSTEM]
Owner process ID 00000000 Dev Prot S:RWPL,O:RWPL,G,W
Reference count 0 Default buffer size 512

Device EIA2:, device type i82559, is online, network device.

Error count 0 Operations completed 3
Owner process "DNS$ADVER" Owner UIC [1,3]
Owner process ID 0000020E Dev Prot S:RWPL,O:RWPL,G,W
Reference count 1 Default buffer size 1492

Device EIA3:, device type i82559, is online, network device.

Error count 0 Operations completed 3
Owner process "DNS$ADVER" Owner UIC [1,3]
Owner process ID 0000020E Dev Prot S:RWPL,O:RWPL,G,W
Reference count 1 Default buffer size 1492

Device EIA4:, device type i82559, is online, network device.

Error count 0 Operations completed 0
Owner process "" Owner UIC [SYSTEM]
Owner process ID 00000000 Dev Prot S:RWPL,O:RWPL,G,W
Reference count 1 Default buffer size 1492

Device EIA5:, device type i82559, is online, network device.

Error count 0 Operations completed 0
Owner process "" Owner UIC [SYSTEM]
Owner process ID 00000000 Dev Prot S:RWPL,O:RWPL,G,W
Reference count 1 Default buffer size 1492

Device EIA6:, device type i82559, is online, network device.

Error count 0 Operations completed 17888
Owner process "DTSS$CLERK" Owner UIC [1,3]
Owner process ID 00000213 Dev Prot S:RWPL,O:RWPL,G,W
Reference count 1 Default buffer size 1492

Device EIA7:, device type i82559, is online, network device.

Error count 0 Operations completed 0
Owner process "" Owner UIC [SYSTEM]
Owner process ID 00000000 Dev Prot S:RWPL,O:RWPL,G,W
Reference count 1 Default buffer size 1500

Device EIA8:, device type i82559, is online, network device.

Error count 0 Operations completed 0
Owner process "" Owner UIC [SYSTEM]
Owner process ID 00000000 Dev Prot S:RWPL,O:RWPL,G,W
Reference count 1 Default buffer size 1500

Device EIA9:, device type i82559, is online, network device.

Error count 0 Operations completed 0
Owner process "" Owner UIC [SYSTEM]
Owner process ID 00000000 Dev Prot S:RWPL,O:RWPL,G,W
Reference count 1 Default buffer size 1500

Device EIA10:, device type i82559, is online, network device.

Error count 0 Operations completed 0
Owner process "" Owner UIC [SYSTEM]
Owner process ID 00000000 Dev Prot S:RWPL,O:RWPL,G,W
Reference count 1 Default buffer size 1500

Device EIA11:, device type i82559, is online, network device.

Error count 0 Operations completed 0
Owner process "" Owner UIC [SYSTEM]
Owner process ID 00000000 Dev Prot S:RWPL,O:RWPL,G,W
Reference count 1 Default buffer size 1500

Device EIA12:, device type i82559, is online, network device.

Error count 0 Operations completed 0
Owner process "" Owner UIC [SYSTEM]
Owner process ID 00000000 Dev Prot S:RWPL,O:RWPL,G,W
Reference count 1 Default buffer size 1500

Device EIA13:, device type i82559, is online, network device.

Error count 0 Operations completed 0
Owner process "TCPIP$INET_ACP" Owner UIC [SYSTEM]
Owner process ID 00000218 Dev Prot S:RWPL,O:RWPL,G,W
Reference count 1 Default buffer size 1500

Device EIA14:, device type i82559, is online, network device.

Error count 0 Operations completed 0
Owner process "TCPIP$INET_ACP" Owner UIC [SYSTEM]
Owner process ID 00000218 Dev Prot S:RWPL,O:RWPL,G,W
Reference count 1 Default buffer size 1500

Device EIA15:, device type i82559, is online, network device.

Error count 0 Operations completed 0
Owner process "TCPIP$INET_ACP" Owner UIC [SYSTEM]
Owner process ID 00000218 Dev Prot S:RWPL,O:RWPL,G,W
Reference count 1 Default buffer size 1500

All network hardware (switches/routers) are Meraki or Cisco, connected via 10Gb fiber links and mostly 1Gb ports. The OpenVMS server itself is limited to a 100Mb connection.

H:\>ping 172.27.20.10

Pinging 172.27.20.10 with 32 bytes of data:
Reply from 172.27.20.10: bytes=32 time<1ms TTL=63
Reply from 172.27.20.10: bytes=32 time=1ms TTL=63
Reply from 172.27.20.10: bytes=32 time<1ms TTL=63
Reply from 172.27.20.10: bytes=32 time<1ms TTL=63

Ping statistics for 172.27.20.10:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 1ms, Average = 0ms

H:\>tracert 172.27.20.10

Tracing route to 172.27.20.10 over a maximum of 30 hops

1 1 ms <1 ms <1 ms 172.27.21.1
2 <1 ms <1 ms <1 ms 172.27.20.10

Trace complete.

I hope this includes everything you needed. I've also tested connecting up to five FileZilla clients simultaneously, all transferring some large log files from the OpenVMS server тАФ each transffered at approximately the same speed (~9.KiB/s).

Let me know if you need any further details.

Best regards,
Bob Smith

PS: Got this message when I posted, not sure what it removed

"Your post has been changed because invalid HTML was found in the message body. The invalid HTML has been removed. Please review the message and submit the message when you are satisfied."

Steven Schweda
Honored Contributor

Re: Slow FTP transfers

   Ok.  Apparently V7.1-2 is too old for "SHOW DEVI /FULL Exy0" to
include stuff like this:

Operating characteristics: Link up, Full duplex, Autonegotiation, Jumbo frames.

      Speed (Mbits/sec) 1000
      Def. MAC addr 00-30-6E-39-76-DF   Current MAC addr AA-00-04-00-8C-04

 

I was hoping to get confirmation of the Ethernet speed, but I suppose
that 9kB/s is still the wrong order of magnitude, even for 10Mb/s.  And
the "Error count 0" suggests no obvious network hardware trouble (on the
VMS side).

   If it's convenient (enough), I might try a reduced LAN: only the VMS
system and the Windows laptop running FileZilla.

> The file is being transferred to a Windows laptop running FileZilla
> Client. [...]

The only problem I remember with sloth in old VMS FTP software was in
_creating_ (extending) a large file on the VMS side, which you're not
doing.  (Lame default RMS parameters could make extending a new file
pretty slow if highwater marking was enabled, but probably not this
slow.)

   Generic at-straws-grasping follows...

   FileZilla on the Windows laptop has no such trouble with any other
FTP server?

   Any other FTP clients/systems available to try instead of that one?
(Different computer?  Windows built-in command-line FTP client?)

   What kind of storage is involved on the VMS system?  Local SCSI
disks, or something fancy?  (SAN? Anything non-local or otherwise
exotic?)

   For better blame-assignment (always Job One), I'd try varying the I/O
style.  For example, on the VMS system:

   COPY big_file NL:   ! Is reading the file slow?

   COPY big_file same_disk:[other_dir]   ! Is reading+writing the file slow?

   COPY big_file other_disk:[any_dir]   ! Is reading+writing the file slow?

   Repeat with BACKUP instead of COPY.  (Should matter little?)

   Use FTP to transfer the file from the VMS system to itself (same
disk, other disk).

   SHOW DEVI /FULL disk_device   ! Look for serious "Error count" value?

   Is the VMS system slow/busy at any other task(s)?  MONITOR SYSTEM ?


> "Your post has been changed because invalid HTML was found [...]

   I haven't seen this in a long while, so I know nothing, but anything
with a GT or LT sign might trigger it.

 

   I wish that I had more specific suggestions.

SmokeyBob
Established Member

Re: Slow FTP transfers

Thanks for the info Steven,

Some of your suggestions led me to find some other commands

 

BRISTOL $ MCR LANCP SHOW DEVICE EIA0 /CHARACTERISTICS

Device Characteristics EIA0:
Value Characteristic
----- --------------
1500 Device buffer size
Normal Controller mode
External Internal loopback mode
00-50-8B-65-D3-98 Hardware LAN address
Multicast address list
CSMA/CD Communication medium
FF-FF-FF-FF-FF-FF Current LAN address
64 Minimum receive buffers
128 Maximum receive buffers
No Full duplex enable
No Full duplex operational
TwistedPair Line media type
100 Line speed (mbps)

BRISTOL $ MCR LANCP SHOW DEVICE EIA0 /COUNTERS

Device Counters EIA0:
Value Counter
----- -------
3461635 Seconds since last zeroed
4010285192 Bytes received
24098561510 Bytes sent
55580020 Packets received
27650365 Packets sent
2167058742 Multicast bytes received
3319474 Multicast bytes sent
29307271 Multicast packets received
46659 Multicast packets sent
9 Unrecognized unicast destination packets
5534502 Unrecognized multicast destination packets
0 Unavailable station buffers
0 Unavailable user buffers
0 Alignment errors
0 Frame check errors
0 Frame size errors
0 Frame status errors
0 Frame length errors
0 Frame too long errors
0 Data overruns
0 Send data length errors
0 Receive data length errors
0 Transmit underrun errors
0 Transmit failures
0 Carrier check failures
0 Station failures
182708 Initially deferred packets sent
648316 Single collision packets sent
21627 Multiple collision packets sent
0 Excessive collisions
605775 Late collisions
0 Collision detect check failures

There seems to be a problem with switch auto-negotiation and the Ethernet card defaulting to half-duplex. I changed the switch setting to force 100Mb half-duplex and will try another transfer to see if it helps.

Do you know if the i82559 Ethernet controller supports full duplex on the AlphaServer ES40? This old hardware is fun to work with, but also pretty frustratingтАФmost of the information I find relates to newer hardware or software versions.

.Thanks for your help!

Best Regards,

Bob Smith

SmokeyBob
Established Member
Solution

Re: Slow FTP transfers

UPDATE:

I tried this after I sent the last reply:

 

BRISTOL $ MCR LANCP SET DEVICE EIA0 /FULL_DUPLEX
BRISTOL $ MCR LANCP SHOW DEVICE EIA0 /CHAR

Device Characteristics EIA0:
Value Characteristic
----- --------------
1500 Device buffer size
Normal Controller mode
External Internal loopback mode
00-50-8B-65-D3-98 Hardware LAN address
Multicast address list
CSMA/CD Communication medium
FF-FF-FF-FF-FF-FF Current LAN address
64 Minimum receive buffers
128 Maximum receive buffers
Yes Full duplex enable
Yes Full duplex operational
TwistedPair Line media type
100 Line speed (mbps)

Went back to the switch and changed it to 100Mb Full Duplex Forced, toggled the port on and off. Rechecked EIA0

BRISTOL $ MCR LANCP SHOW DEVICE EIA0 /CHAR

Device Characteristics EIA0:
Value Characteristic
----- --------------
1500 Device buffer size
Normal Controller mode
External Internal loopback mode
00-50-8B-65-D3-98 Hardware LAN address
Multicast address list
CSMA/CD Communication medium
FF-FF-FF-FF-FF-FF Current LAN address
64 Minimum receive buffers
128 Maximum receive buffers
Yes Full duplex enable
Yes Full duplex operational
TwistedPair Line media type
100 Line speed (mbps)

Tried the FTP transfer again and was able to transfer the 1.4Gb file in 123secs. Wow what a difference.

Thanks for getting me pointed on the correct path.

Best Regards,

Bob Smith

SmokeyBob
Established Member

Re: Slow FTP transfers

Hi Steven,

One quick question, will the changes I made persist through a reboot? This Server has been locking up and having to be rebooted as often as every couple of weeks, hence why we are making exports of the database as often as possible to lose as little data as posible while we are building a new server which is taking longer than expected.

Steven Schweda
Honored Contributor

Re: Slow FTP transfers

> [...] Wow what a difference.

   Thanks for the good-news report.

> BRISTOL $ MCR LANCP SHOW DEVICE EIA0 /CHARACTERISTICS

   Ah, yes. I remember LANCP (with a little reminder).  I just haven't
needed to use it for a very long time.  My home museum uses only
unmanaged switches, and I've never seen a problem with this stuff.

> There seems to be a problem with switch auto-negotiation and the
> Ethernet card defaulting to half-duplex. [...]

   Did the switch agree about the half-duplex part?  I might dimly
recall reading (long ago) about auto-negotiation problems, but I never
experienced any.  I know nothing, but I wouldn't expect half-duplex done
properly to have that big an effect.  Perhaps if only one end thinks it
can do full...?

> Do you know if the i82559 Ethernet controller supports full duplex on
> the AlphaServer ES40?

   At VMS V7.1-2, I know nothing, but I'd expect it to.  Could be a bug
in SYS$EIDRIVER.  If so, it's probably been fixed in recent decades, but
that wouldn't help you if you're stuck with the old software.

   For a good time, you might explore your SYS$SYSTEM:SYS$CONFIG.DAT,
and see if there's a nice antique (cheap) gigabit Ethernet card you
might be able to stick into a lonely PCI slot.

   For example, I have an XP1000 workstation with built-in "Fast
Ethernet", but I added a gigabit card:

ALP $ sh dev /fu ewa0   ! Built-in "Fast".

Device EWA0:, device type DE500, is online, network device, error logging is
enabled, device is a template only.

    Error count 0     Operations completed 0
    Owner process ""     Owner UIC [SYSTEM]
    Owner process ID 00000000     Dev Prot S:RWPL,O:RWPL,G,W
    Reference count 0     Default buffer size 512

Operating characteristics: Link down, Autonegotiation.

    Speed (Mbits/sec) 10
    Def. MAC addr 08-00-2B-86-59-46     Current MAC addr AA-00-04-00-5F-04

ALP $ sh dev /fu ewb0   ! Add-in Broadcom card.

Device EWB0:, device type BCM5703, is online, network device, error logging is
    enabled, device is a template only.

    Error count 0     Operations completed 0
    Owner process ""     Owner UIC [SYSTEM]
    Owner process ID 00000000     Dev Prot S:RWPL,O:RWPL,G,W
    Reference count 0     Default buffer size 512

Operating characteristics: Link up, Full duplex, Autonegotiation, Jumbo frames.

    Speed (Mbits/sec) 1000
    Def. MAC addr 00-10-18-10-37-09     Current MAC addr AA-00-04-00-5F-04

   Of course, my software's fresher than yours:

ALP $ tcpip show version

HP TCP/IP Services for OpenVMS Alpha Version V5.7 - ECO 5
on a COMPAQ Professional Workstation XP1000 running OpenVMS V8.4-2L1

 

> [...] will the changes I made persist through a reboot? [...]

   I'd check the manual, but I'd guess that SET changes the volatile
data, while DEFINE changes the permanent data.  I'd expect only one of
those to survive a shut-down.

      https://docs.vmssoftware.com/vsi-openvms-system-management-utilities-reference-manual-volume-i-a-l/

Worst case: Add your commands to SYS$MANAGER:SYSTARTUP_VMS.COM (but I
wouldn't expect that to be necessary.)

 

> [...] building a new server which is taking longer than expected.

   In my (limited) experience, almost every task takes longer than
expected.