Operating System - OpenVMS
1748180 Members
4054 Online
108759 Solutions
New Discussion юеВ

V8.3-1H1 Installed with Gigabit nics and slow net performance

 
Stuart Green
Frequent Advisor

V8.3-1H1 Installed with Gigabit nics and slow net performance

I get slow network performance on my new I64 box with gigabit nics.
I have them plugged into cisco switches. The switch ports are auto-auto gigabit.

Copying file from a 1.0Gb machine to my integrity server and only get approx 5Mb/s transfer.

Should I be setting the OS to use Jumbo frames and also have the switch ports reconfigured.?
I have seen some performance tips on the net but cant find anything on HP.com about setting this on the OS.

Note: This is a standalone box.

Thanks for any assistance.
21 REPLIES 21
Volker Halle
Honored Contributor

Re: V8.3-1H1 Installed with Gigabit nics and slow net performance

Stuart,

trying to judge NIC speed by copying files around involves too many other possible bottlenecks.

If you have another system running OpenVMS and DECnet, run a DTSEND test.

Or copy a file to the null device on OpenVMS, this eliminates possible issues with writing the file to disk:

FTP your-vms-system
...
FTP> PUT localfile NLA0:

Volker.
Robert Gezelter
Honored Contributor

Re: V8.3-1H1 Installed with Gigabit nics and slow net performance

Stuart,

As a start, I would look the error counters on the switch ports, and both hosts involved in the transfer. Any significant number of collisions or retransmissions is a red flag.

Consider setting the switch appropriately and using WireShark to capture the entire conversation, then look at what is actually causing the delay.

- Bob Gezelter, http://www.rlgsc.com
Richard Whalen
Honored Contributor

Re: V8.3-1H1 Installed with Gigabit nics and slow net performance

Setting the nics up for jumbo frames could be what you need to do to realize the expected data rate from these nics. Since the nics have a high signal rate, they can receive (or transmit) a packet very quickly; unfortunately, there is enough fixed overhead in getting a packet from the user application to the wire that the throughput is reduced unless you go to larger packets.
Steve Reece_3
Trusted Contributor

Re: V8.3-1H1 Installed with Gigabit nics and slow net performance

Hi Stuart,

You say copy a file, but you don't mention how you're doing the copy. Windows protocols and SMB take a large overhead on data verification. With FTP, there's the stepping down the network stack and packaging things up for the network card to do before it ever gets to the wire.

Have you looked at LANCP at what the ports have actually configured themselves as? It could be that negotiation is the culprit here and the Cisco switch and the Integrity have negotiated a much slower speed than you are expecting. There may also be contention on the wire.

Steve
Hein van den Heuvel
Honored Contributor

Re: V8.3-1H1 Installed with Gigabit nics and slow net performance

What is the copy command used? FTP?
What is on the other side?

Out-of-the-box OpenVMS is NOT set up for speedy FTP's.

What makes you think is is a network issue?
Was it any faster on 100mb?

How are the disks and CPU doing during the transfer. They should hardly move.

Did you calibrate with
- a local FTP over loopback?
- NL: device output
- disk-to-disk copy.
- reverse direction copy.. from VMS to PC.

Did you measure disk activity?
Disable High-Water-Marking on the output disk? (SET VOLUM/NOHIGH)
Checked SHOW RMS? for buffer/blocks/extent?

Check with Google for prior topics in thsi space. For example:

http://forums11.itrc.hp.com/service/forums/questionanswer.do?threadId=1341603


Hope this helps,
Hein van den Heuvel
John Gillings
Honored Contributor

Re: V8.3-1H1 Installed with Gigabit nics and slow net performance

Stuart,

I remember a case where a customer wasn't getting expected network throughput copying files after upgrading from 10MB to 100MB.

The throughput was more than 10MB, but only just. After spending quite some time checking all network components in the path between the nodes, it turned out the bottleneck was the write performance of the destination disk drive!

Try to eliminate as many factors as possible when testing.
A crucible of informative mistakes
Cass Witkowski
Trusted Contributor

Re: V8.3-1H1 Installed with Gigabit nics and slow net performance

We experienced slower performance with jumbo frames enabled because the site's LAN switch did not support Jumbo frames.
Robert Gezelter
Honored Contributor

Re: V8.3-1H1 Installed with Gigabit nics and slow net performance

Stuart,

Before going too far down this investigation, please verify what RMS buffering parameters are in use on both sides.

In particular, you are interested in the /BLOCK, /BUFFER, and /EXTEND settings. Of the three, /EXTEND is the often the most time consuming.

Remember, an extend of 100 blocks will not last very long at 1Gb.

- Bob Gezelter, http://www.rlgsc.com
Hein van den Heuvel
Honored Contributor

Re: V8.3-1H1 Installed with Gigabit nics and slow net performance

Stuart,

Is the copy operation you used to verify the speed believed to be representative of the actual usage of the link? Will the link's dominant usage be similar to the copy used to test it?

If it is, then let's figure out an expectation and figure out whether it lives up to that, and perhaps why it does not perform as expected.
Your expectation is probably 100 MB/sec.
Well, can you source that?
Can you sink it?

But if it isn't, then let's try to characterize the real load, and somehow measure that. Maybe latency is more relevant than throughput? Or packets/sec?

You may want to find, or write, a little tool to volley some request/response packets back and forward with selectable concurrency and measure its performance.
I'm sure stuff like that is out there, and I know that when I wrote one for a special test (mimic SAP messages) it was immensely more valuable than the 'quick' ftp test we relied on before.

Knowing how say FTP or NFS behaved helped, but the real McCoy is the application itself or something that closely mimics it (similatr packet sizes, rates, active port counts, active ip addresses, it may all matter.


Cheers,
Hein van den Heuvel