VMS 7.3-2 Copy slow on Alpha

[Volker Halle]

Mark,

yes, it's called NSP MAXIMUM WINDOW and MAXIMUM RECEIVE BUFFERS.

That's why I asked for checking of all the parameters for the various DECnet-OSI entities.

Volker.

[Volker Halle]

John,

did you ever try to reproduce this behaviour with COPY/FTP ?

Volker.

[John_TT]

Hi, I finally woke up and started the trace, nodeA_trace.log and nodeB_trace.log attached. Also attached are nodeA.log and nodeB.log with the NCL OSI parameters (I would have posted them sooner but the copy took a while...). I ran a slow then fast copy during trace.

I have 2 systems on test with only Decnet running, nothing else is started, but copy /ftp worked fast.

[Robert Gezelter]

John,

If I understand your last posting correctly, the COPY over DECnet performs poorly, but the equivalent FTP transfer performs in line with expectations.

If the connections are TRULY through the same path (something to be confirmed with a LAN Analyzer, e.g. WireShark -- NOT with displayed settings -- in this case I prefer hard observable data where possible), the excludes the network.

Quotas associated with DECnet are a possibility, as has been already discussed. Also, please check the RMS parameters (SHOW RMS) from within the NETWORK receiver process. I can imagine a situation where disk fragmentation, and the resulting ongoing extends, create a bottleneck in transfer performance.

As an experiment, try increasing the RMS EXTEND, BUFFER, and BLOCK parameters in the LOGIN.COM file for the server account (say EXTEND=2000, BUFFER=128, and BLOCK=127; it may also be necessary to increase the accounts page related quotas and working set). See what happens.

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

[John_TT]

Hi Bob, The show rms command from the account I am using shows all zero's except for:
System multi block count = 32 and System network block count 127 (on both systems).

[Volker Halle]

John,

I'm unable to download your attachment. Feel free to mail it to me (see my ITRC profile).

Regarding the quotas: note that you've successfully done a local copy on NodeB to NodeB::filename - bypassing the physical network. This should have also been slow, if there would be problems with disk-access, quotas etc. Please make sure, that you are using the same username for the 'remote' FAL process on NodeB in both test scenarios.

Volker.

[Hein van den Heuvel]

FTP has LOGICAL NAME options which, when set, may potentially be helping its performance a lot. Notably: TCPIP$FTP_FILE_ALQ and TCPIP$FTP_FILE_DEQ, but others exist:

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

I expect DECnet to just listen to RMS defaults.

MBC=32 is the new default, but is it sill on the low side. At least double that, or max out to 127. Some suggest the highest possible mutliple of 16 (112) might work slightly better XFC and Storage interactions.

You also want some more buffers. Like 4 or 8.
Going from 1 to 2 is potentially the big winner. Rapidly diminishing returns beyond that. I don't trust 127 buffers. That seems too high to help and may hinder. Try it though, as your mileage may, and will, vary.

Did you check for fragmentation on the output files as I suggested in an earlier reply?
$ pipe dump /head/bloc=count=0 | sea sys$pipe "Extension file"


Regards,
Hein van den Heuvel ( at gmail dot com )
HvdH Performance Consulting.

[Oswald Knoppers_1]

"
NodeA: Lancp shows no errors on EWA0 (DE500-BA), 4x unrecognised multicast packets. And EWB0 (Not configured for Decnet!) shows last error at 18:07 Today and 3105 carrier check failures?
NodeB: Lancp shows no errors on EWA0 (DE500-BA), And EWB0 (Not configured for Decnet!) shows last error at 18:03 Today and 300 carrier check failures?
"

Are you sure the EWB0 devices are not configured for DECnet? Net$configure (in basic mode) will configure all lan devices it can find for DECnet. Check this with:

$ mc ncl sho routing circuit *

Do you have any routers involved?

$ mc ncl sho routing circuit xxx adja * all

Oswald

[John_TT]

Hello, I have increased the NSP MAX WINDOW parameter from 20 to 120 and seem to have consistent "fast" copy transfers on my test systems... Here are the MC NCL SHOW NSP ALL characteristics, any comments? Should "Congestion Avoidance" be FALSE ?

I'm off to try another system or 2...

$ MC NCL SHOW NSP ALL
Characteristics

Maximum Transport Connections = 200
Maximum Receive Buffers = 4000
Delay Weight = 3
Delay Factor = 2
Maximum Window = 20
DNA Version = T4.2.1
Acknowledgement Delay Time = 3
Maximum Remote NSAPS = 201
NSAP Selector = 32
Keepalive Time = 60
Retransmit Threshold = 8
Congestion Avoidance = False
Flow Control Policy
=Segment Flow Control

[Willem Grooters]

Since averyone seems to agree it's DECNet causing the trouble, I would ask a few other questions on the behaviour:

* Does it happen with the same pair(s) of nodes, or is it random?
* Does it happen on the same files, for each pair, or is it random?
* How fragmenetd is teh source disk?
* Is the file sereverly fragmented?
* How fraggmented is the destination disk?
* What's the extent size on thre receiving system?
* Have you thought turning off Highwater marking during COPY?
* If these files are indexed, how good (or bad) is the internal structure, and how are the buckets located on disk?

Willem