Everything you want and need to know about Oracle SPARC systems performance

Improved Oracle Solaris 10 1/13 Secure Copy Performance for High Latency Networks

Brian Whitney
Principal Software Engineer

With Oracle Solaris 10 1/13, the performance of secure copy or "scp" is significantly improved for high latency networks.

  • Oracle Solaris 10 1/13 enabling a TCP receive window size up to 1 MB has up to 8 times faster transfer times over the latency range 50 - 200 msec compared to the previous Oracle Solaris 10 8/11.

  • The default TCP receive window size of 48 KB delivered similar performance in both Oracle Solaris 10 1/13 and Oracle Solaris 10 8/11.

  • In this study, settings above 1 MB for the TCP receive window size delivered similar performance to the 1 MB results.

  • The tuning of the TCP receive window has been available in Oracle Solaris
    for some time. This improved performance is available with Oracle Solaris 10 1/13 and Oracle Solaris 11.

Performance Landscape

Configuration Summary

Test Systems:

SPARC T4-4 server
4 x SPARC T4 processor 3.0 GHz
1 TB memory
Oracle Solaris 10 1/13
Oracle Solaris 10 8/11
Sun Fire X4170 M2
2 x Intel Xeon X5675 3.06 GHz
48 GB memory
Oracle Solaris 10 1/13
Oracle Solaris 10 8/11

Driver System:

Sun Fire X4170 M2
2 x Intel Xeon X5675 3.06 GHz
48 GB memory
Oracle Solaris 10

Router / Programmable Delay System:

Sun Fire X4170 M2
2 x Intel Xeon X5675 3.06 GHz
48 GB memory
Oracle Solaris 10

Switch in between the router and the 2 test systems

Cisco linksys SR2024C

Benchmark Description

This benchmark measures the "scp" performance between two systems with variable router delays in the network between the two systems. A file size of 48 MB was used while measuring the affects of varying the latency (network delays) and varying the TCP receive window size.

Key Points and Best Practices

  • The WAN emulator (aka. "hxbt") is used in the router to achieve delays. Verification of network function and characteristics confirmed after setting the simulator using Netperf latency and bandwidth tests between driver and test system.
  • Transfers performed over 1 GbE private, dedicated network.
  • Files were transferred to and from "/tmp" (i.e. in memory) on the test systems to minimize effect of filesystem performance and variability on the measurements.
  • Larger TCP receive windows than default can be enabled using the system-wide parameter "tcp_recv_hiwat" (e.g. to enable 1024 KB windows using this method, use the command: "ndd -set /dev/tcp tcp_recv_hiwat 1048576"). To make this change persistent the command will have to be added to system startup scripts.
  • "sshd" on target system must be restarted before any benefit can be observed after increasing the enabled tcp receive buffer size. (e.g: can restart with the command "/usr/sbin/svcadm restart svc:/network/ssh:default")
  • Note that "tcp_recv_hiwat" is a system-wide variable that adjusts the entire TCP stack. Care, therefore, must be taken to make sure that changes do not adversely affect your environment.
  • Geographically distant servers can be affected by connection latencies of the kind presented here.

See Also

Disclosure Statement

Copyright 2013, Oracle and/or its affiliates. All rights reserved. Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners. Results as of 2/08/2013.

Join the discussion

Comments ( 3 )
  • rick joes Monday, February 18, 2013

    There is the old standby formula for one of the limits of the performance of a TCP connection - Throughput <= Window/RTT. So, if throughput at a given RTT were indeed being limited by Window, such as the 48KB window line, why did 128KB, which is 2.5X larger achieve a throughput improvement of only 1.5X? Similarly, one might have expected 256KB windows to be 5.3X rather than 3.0.

    Doesn't there need to be a corresponding ndd change to the "send" side to be able to fill the window being advertised by the receiver?

  • Brian Tuesday, February 19, 2013

    Concerning your 1.5x comment, the improvements listed are from the older OS to the new OS. It is not the performance improvement seen by changing the window size. The performance exhibited with the new OS is as expected as the window size changes

    (as you expect as stated in your comment).

  • Brian Thursday, February 21, 2013

    Concerning the second comment, the simple answer is the results were obtained without any TCP tuning on the send side.

Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.