COPY/FTP error

[gunners]

Hi there folks, I am getting the error below when trying to copy/ftp

Decnet copy works fine but someone suggested that I use copy/ftp as some of the files are huge and were taking hours to copy across. (the password below I have as 'password' for obvious reasons)

copy/ftp/lo DSA1501:[ibid91_sync_savesets]dsa1200.bak ibid91"system password"::dsa1501:[temp_backups]*.*

IBID90::_FTA298: 10:30:44 TCPIP$FTP CPU=00:07:45.14 PF=19148 IO=8804975 MEM=534

IBID90::_FTA298: 10:30:45 TCPIP$FTP CPU=00:07:45.15 PF=19148 IO=8804976 MEM=534

IBID90::_FTA298: 10:30:45 TCPIP$FTP CPU=00:07:45.15 PF=19148 IO=8804977 MEM=534

%TCPIP-E-FTP_NETERR, I/O error on network device

-SYSTEM-F-TIMEOUT, device timeout

[Ian Miller.]

why where the copies using DECnet taking a long time? 

suggests all is not well with your network.

[gunners]

Hi There Ian,

I should have mentioned that the servers are in two locations - about 10 miles apart. The network is pretty good by all accounts and even with the major traffic from me yesterday (about 8million blocks) worth of files , there was no impact to users of other systems (who also use this link)

[Volker Halle]

Hi,

you've typed CTRL-T a couple of times, but the IO counter only increased by 1 each time, so there were no IOs being done by COPY/FTP. And the copy finally failed, so there has been a network connectivity issue.

If there are packets getting lost on that link between the 2 systems, DECnet will take a lot time to retransmit packets, which will make the perceived 'performance' look bad.

Volker.

[John Gillings]

gunners,

   This sounds like a duplex mismatch to me. Check that the entire path between systems either has matching settings between NIC and switch ports. I recommend AUTONEGOTIATE everywhere, but if that's not possible, ensure that if any port has a hard setting, that it matches exactly at both ends.

  If one end is st to (say) 100 Full Duplex and the other end is AUTO, the auto end will configure as 100 Half Duplex. On a lightly loaded network this is rarely an issue. So things like telnet "work fine". However, when you start loading it with things like file transfers the half duplex end will start missing packets and requesting retransmissions, leading to excessive transfer times and/or timeouts.

  Many years ago a myth developed that OpenVMS doesn't handle network autonegotiation. It may have been true of mixtures of specific nics, brands of switches and (ancient) versions of network software, but for anything produced in the last decade or two, everything just works. If your site policies have a voodoo belief in "autonegotiate bad", please try to change it. (On the other hand, the continued prevalence of duplex mismatches keep many support staff in work, with the ability to easily achieve apparently miraculous fixes)

[gunners]

John , that sounds like a strong possibility. How would I check the settings ? - something like SHOW DEVICE 'device name' / FULL ?

[Volker Halle]

Does PING or TELNET work between those 2 systems ?

You can look at the console messages issued by the LAN driver with $ MC LANCP SHOW DEVICE/INTERNAL

This will show you 'possible duplex mismatch' errors detected and reported by the LAN driver. It will also show you the LAN startup messages, which should tell you the settings of the LAN device(s) at console level, and the link state.

Then you need to talk to your network people about the status of the switch ports, to which the LAN interfaces are connected.

Volker.

[gunners]

Hi there Volker ,

Yes indeed telnet works fine. I ran that LAN command on the 'receiving' server.

It seems from what I can make out that it has correct settings from some of the output here ?

000002A4 Requested link state <FlowControl, Fdx, 1000 mb,

Auto-negotiation>

000002A5 Current link state <FlowControl, Fdx, 1000 mb,

Auto-negotiation, Link up>

1 Link up timer

[Volker Halle]

That looks fine.

And how about the sending server ?

Volker.

[gunners]

Hi again Volker ,

ok here is a snapshot from the 'sending' servers config using the same LAN command

9856 Jumbo buffer size (bytes)

9018 Jumbo packet size (bytes)

000002A4 Requested link state <FlowControl, Fdx, 1000 mb,

Auto-negotiation>

000002A5 Current link state <FlowControl, Fdx, 1000 mb,

Auto-negotiation, Link up>

00001010 Driver flags <82571EB (Ophir), Copper>

00000004 Driver state <RunUp>

PCI-Express BUS type