[Info-vax] VMS to VMS data copy options/performance when losing a DECnet link

[Simon Clubley]

On 2022-04-20, Rich Jordan <jordan at ccs4vms.com> wrote:
>
> Main VMS server and PC backup server on the same LAN, second VMS server
> at the remote site.  The test saveset was one of the small ones; I'll need
> to get times on the three much larger ones.
>
> Main VMS to local PC backup server transfers a 6.7M block backup file in
> 3 minutes 41 seconds
> Main VMS to remote VMS transfers same file in 32 minutes 21 seconds (push
> or pull)
> Remote VMS server pulls the same backup file from the PC backup server in
> 10 minutes 30 seconds.
>

That middle VMS to VMS time is especially pathetic.

Once the production version of VMS is available, someone should do
some testing comparing the time it takes to move data across the
network on the same hardware using both Linux and VMS.

If the results are anything like the above, that might shame
VSI Engineering into allocating engineering time to track down
the performance problems and fix them.

> So it is faster to relay backups (and presumably other data of any
> significant size) through the PC backup server than doing it directly VMS
> to VMS.
>

[snip]

> For now I guess we'll have to live with it.  I'll try setting up sftp/scp
> to test but everything I've read says those will be slower.
>

I don't suppose there are any auto-negotiation LAN interface setting
problems (or similar) are there ?

Are any errors being logged at physical network interface level ?

Do you have access to SMB on the VMS systems ?

If so, I wonder if SMB would show better performance.

If it does, then for goodness sake test the hell out of it before
switching to using that method!!!

Simon.

-- 
Simon Clubley, clubley at remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.