Changes between Version 21 and Version 22 of Gigabit_Networks_Linux

10/03/18 08:41:54 (2 years ago)

Add brief notes about --txqueuelen parameter


  • Gigabit_Networks_Linux

    v21 v22  
    3535By switching to the cipher '''aes-256-cbc''' the performance drops even further to '''126 Mbps'''. These results were obtained on the two E5440 based servers.
    3738== Tweaked setup ==
    3839The first tweak made was:
    7071=== Explanation ===
    7172By increasing the MTU size of the tun adapter '''and''' by disabling OpenVPN's internal fragmentation routines the throughput can be increased quite dramatically. The reason behind this is that by feeding larger packets to the OpenSSL encryption and decryption routines the performance will go up. The second advantage of not internally fragmenting packets is that this is left to the operating system and to the kernel network device drivers. For a LAN-based setup this can work, but when handling various types of remote users (road warriors, cable modem users, etc) this is not always a possibility.
     74== '''txqueuelen''' ==
     76The default value for '''tx_queue_len''' in linux is 1000, however, openvpn overrides this default and sets it to 100. You can re-set it to the original default of 1000 by specifying '''--txqueuelen 1000'''. This can greatly improve throughput in scenarios where using jumbo frames ('''--tun-mtu''') is not possible, such as over the internet. The expected performance gain is around 5x, being from 60mbps to almost 300mbps on some tests I carried on a real coast-to-coast scenario (with different ISPs).
     78|| '''txqueuelen''' || '''bandwidth''' ||
     79||  100||63 ||
     80|| 1000||292 ||
     82Please note that, as the name indicates, this only affects the transmission, not the reception. So in case an asymmetric connection is used, this parameter will only have an observable effect on a peer whose transmission speed is greater than ~100mbps.
    7384== Using OpenSSL 1.0.0 with AES-NI patch ==