VMS 7.3-2 Copy slow on Alpha

[Hein van den Heuvel]

Volker>> If all the DTSEND test show accetable performance and copy doesn't, you have to think about where the bottleneck may be.

When I first read this problem and did a back-of-the-enveloppe calculation on how slow the disk would have to be if there was a filesystem/disk problem involved.

Well, in a worst-case 1 block IO, that would be 50,000 / ( 24*60 ) = 34 IO/sec. But 1 block IOs are unlikely. Maybe 16 block IOs with a 32 block extend every 16 blocs? That would be 5+ IOs every 32 block = 8000 IOs, which would only be 5 IO/sec. Too easy.

Still... best check!
RMS Settings: (EXTEND, SEQ BLOCKS, NETWORK BLOCKS)
$SHOW RMS

and file fragmentation on the OUTPUT side after the copy:
$DUMP/HEAD/BLO=COUNT=0 slow_output.dat

Or perhaps even use an LD device and TRACE all the IOs (or use the XFC trace)

If still desperate, then I would for an explanation, then defining FAL$LOG to 17 (or whatever value to get the data messages logged) or so may be needed. The initial FAL capabilities negotiation may be interesting also.

Good luck!
Hein

[John_TT]

The copy nodeB$ copy fileA.txt nodeB::fileA.txt; works fine, also if I stop and restart decnet the first copy works fast then all others slow.

With dtsend running on both nodes /block=512 /type=echo, monitor decnet shows:
NodeA (DS10)
Arriving local packet rate max 13124 average 6206
Departing local packet rate 6206 average 3089

NodeB (XP900)
Arriving local packet rate max 6271 average 671
Departing local packet rate 13223 average 1459

[John_TT]

... Now I have the copy from nodeB (XP900 to NodeA (DS10) working as expected copy both ways fast. But nodeA to nodeB is still slow... Maybe to be expected after the Decnet stats, what changed?

[Volker Halle]

John,

if you run one DTSEND test and MONITOR DECNET on both nodes at the same time, the arriving/departing packet average values should match each other - if there is no additional DECnet traffic at that time. The counters should also amtch the messages per second reported by DTSEND. You can increase the test interval by /MINUTES=5 to achiev a stable packet rate for monitoring purposes.

What does MONITOR DECnet tell, if you perfm a 'slow copy' ? Is the packet rate constantly slow or is it just ZERO for a long time and then jumps to normal ?

Did you verify the 'Duplicate PDUs Received' and 'Retransmitted PDUs' counters between those 2 nodes in case of the 'slow copy' ?

Volker.

[John_TT]

'Duplicate PDUs Received' and 'Retransmitted PDUs' counters between those 2 nodes in case of the 'slow copy'-- Both = 1 on NodeB and go up to 2 each on nodeA during slow copy.

Monitor decnet during slow copy is constantly slow, rx 4 tx 16 and vice versa on the other node.

Running 1 DTsend arriving/departing packet average values don't match, approx 1:2 as with the monitor decnet stats. And don't match the DTsend numbers.

[Volker Halle]

John,


NodeB (XP900)
Arriving local packet rate max 6271 average 671


Is '671' a typo ?

When I run DTSEND DATA/NODE=xxx/SIZE=512/TYPE=ECHO/MIN=2, I see consistent arriving/departing local packet average rates on both systems with MONITOR DECNET. The systems are idle except for the DTSEND traffic. Departing rate on one node is about the same as arriving rate on the other note (difference in values < 5%).

Did you compare the DECnet-OSI parameters for the various entities ?

Any problems with nonpaged pool (SHOW MEM/POOL/FULL) ?

You can trace DECnet traffic with the CTF$TRACE utility, e.g.

$ TRACE START[/LIVE] "ROUTING CIRCUIT csmacd-0"

Try this for a couple of seconds with a 'fast' and a 'slow' copy. Then compare the results. TRACE ANAL can analyze the traces and output ASCII text files.

Volker.

[Volker Halle]

John,

NodeB (XP900)
Arriving local packet rate max 6271 average 671
Departing local packet rate 13223 average 1459

Assuming this data is correct, while continuously running DTSEND to or from this node. If you now run MONITOR DECNET/INT=1 on this node (logged in via TCPIP or LAT), is the packet rate constant or does it drop to ZERO from time to time ? This would then - again - indicate a problem with lost packets.

Volker.

[John_TT]

Hi Volker,

The numbers are as I stated.

Can't find anything on CTF$TRACE ?

The monitor decnet stats are constantly low for the slow copy.

No pool problems.

I haven't checked the DECnet-OSI parameters for the various entities ?

[Volker Halle]

John,

$ TRACE HELP

or see the 'DECnet/OSI for VMS CTF use' manual on

http://h71000.www7.hp.com/doc/decnetplus83.html

So is only NodeB (XP900) showing 'the problem' then ? DTSEND rates on that node (arrriving packet rate) seem to be 10x slower than on the DS10.

You may need to provide more detailled test results. Run one DTSEND operation at a time, specify the parameters and where it's being run and the message rate achieved. Also provide MONI DECNET date from both nodes involved in the test. Build a table from the data from these tests and find out exactly WHICH operation causes unexpected bad performance.

Compare DECnet-OSI parameters for:

NCL> SHOW NSP ALL
NCL> SHOW SESSION CONTROL ALL
NCL> SHOW ROUTING ALL
NCL> SHOW ROUTING CIRCUIT * ALL

Volker.

[marsh_1]

volker,

does decnet-osi have the equivalents of buffer quota , pipeline quota from phase iv ?