Netgear ReadyNAS Duo V2 and Jumbo Frames

System Requirements:

  • Netgear ReadyNAS Duo V2
  • Firmware 5.3.12
  • 9k compatible NIC’s and intermediate Layer 2/Layer 3 hardware

The Problem:

The ReadyNAS Duo V2 is a now legacy, ARM based dual 3.5″ drive SOHO NAS appliance with a single NIC and 256MB of RAM. The device was never intended to support performance or even low-end enterprise tasks.

The ReadyNAS Duo V2 is not designed for Jumbo Frames and there are no user interface entry points to enable it. It is not clear on-line whether anyone has had any actual success with enabling it. This document explores the issue.

More Info

In wanting to use the device simply as a on-line backup appliance, I wanted to try and squeeze as much performance out of it as I could. One of the obvious things to try is to enable Jumbo Frames, which allows more data to be transmitted in a single Ethernet Frame before the data has to be re-wrapped in a new header and trailer for Layer 2 transmission over an Ethernet Network. The logic being that the fewer CPU cycles being used to process the header and generate and process the CRC and footer, the faster the transfer into memory and thus the smoother the transmission of the data can occur into the disk sub-system.

In order the enable Jumbo Frames, the Maximum Transmission Unit (MTU) has to be adjusted on ALL devices in the transmission path – sender NIC, receiver NIC and any and all intermediary switch ports, bridge ports and router ports. If any one devices does not have Jumbo Frames configured to the same (or higher) value, it will fault. If you have one devices with a higher value and the other devices with a lower value, you will almost certainly see a performance reduction when transmitting from that device. Therefore: Set all of your devices to the same, common MTU values.

Depending on the manufacturer, device and driver these are usually:

Name Rounded Offset
Normal
1500
1514
3K
3000
3014
4K
4000
4088
5K
5000
5014
7K
7000
7014
Note: As a general rule of thumb, if you are using a PCI NIC, this is the largest MTU you can hope to achieve. PCI Express NIC’s can go up to 9k
9K
9000
9014
Note: Specialist enterprise grade hardware is required for MTUs larger than 9K and these sizes are not usually available on 1Gbps NIC hardware (10 or 40Gbps hardware or higher)
16K
16000
16128
24K
24000
32K
32000
64K
64000
Note: This is the maximum transfer size of a TCP Segment

Step 1

This was only tested on Firmware Version 5.3.12. Ensure that your firmware is up to date.

Step 2

You will need to enable Root SSH Access on the device via the official Netgear plugin. Install the plugin via the web UI and reboot the NAS before attempting to proceed.

Download: Enable Root SSH Access Plugin

Step 3

Set a static IP address on the device (or at the very least set and then unset it) to ensure that the config files have been written out correctly. It appears that a clean OS install does not make use of the interfaces file as expected until after a static IP address has been set.

Step 4

SSH into the device (using Bash, Putty for Windows or your preferred client). Usually this is root@<ipaddress>

Step 5

Perform a test to see whether Jumbo Frames currently works

ping <ipaddress> -l 8000

If you receive a successful “reply from…” then it is already working between your ReadyNAS and your PC. The expected result is however for this to fail, indicating that Jumbo Frames is not enabled

Step 6

Perform a volatile test by enabling Jumbo Frames for the session. If you lose contact with your single NIC ReadyNAS, simply reboot it to restore functionality. Under the SSH session issue the following command. If you need to set a lower Jumbo Frame value (for example 7k) change the 9000 value as appropriate.

ip link set dev eth0 mtu 9000

Step 7

Repeat the ping test from your PC

ping <ipaddress> -l 8000

This should now be successful

Step 8

If you wish to make the change permanent so that the setting persists after a restart of the ReadyNAS you must edit the interfaces file. Return to the SSH session

vi /etc/network/interfaces

In VI press i to commence insert mode

Find the entry for the eth0 interface and at the bottom of the section enter mtu 9000 (or the frame setting that you require) e.g.

iface eth0 inet static
address 192.168.0.100
netmask 255.255.255.0
gateway 192.168.0.254
mtu 9000

Note: That is LOWER CASE “mtu”

To save and exit VI press the Escape key and then type :wq (colon, w, q) and press return

Finally type reboot to restart the ReadyNAS

Step 9

Repeat the ping test and you should find Jumbo Frames working

Everything went wrong and now I cannot access my ReadyNAS

Don’t panic. Just access the boot menu and put it into OS Reinstall mode

  1. Turn the ReadyNAS off
  2. Use a paper clip to hold in the reset button on the back
  3. Keep the clip held in place and turn the ReadyNAS on
  4. Hold the paper clip in for 10 seconds
  5. Release the paperclip
  6. Push the backup bottom on the front of the ReadyNAS until the Disk 2 LED is the only one illuminated (be very careful that it is Disk 2 and not Disk 1. Disk 2 reinstalls the OS, Disk 1 factory resets the device and deletes all of your data)
  7. Use the paperclip one more time and single press the reset button to execute the boot menu mode
  8. Come back in 20 minutes and use RAIDar to find your ReadyNAS again (you will have to reconfigure the settings)

Does is make a difference?

Comparing the transfer speed before and afterwards does yield a significant improvement in write speed on the device.

The test configuration

The Source

  • 3.4GB ISO
  • Windows Server 2012 R2
  • From an NTFS formatted 5 disk RAID 5 array on a LSI MegaRaid 8260-8i with caching an optimisation’s enabled
  • A Quad Port Intel I350-T4 Gigabit Server NIC with Jumbo Frames set to 9014 bytes
  • Cat 5e cabling
  • 3 intermediate switches all supporting Jumbo Frames

The Destination

  • ReadyNAS firmware 5.3.12
  • Dual WD Red 3TB WD30EFRX-68AX9N0 with 64MB cache (only 5400 RPM)
  • Write caching enabled on the ReadyNAS
  • The ReadyNAS is running in Flex-RAID RAID 0

To enable write caching over SSH:

hdparm -W1 /dev/sda
hdparm -W1 /dev/sda1
hdparm -W1 /dev/sda2
hdparm -W1 /dev/sda3

Transferring the same 3.4GB ISO from the same Windows Server 2012 R2 NTFS volume over the same NIC/Network/Switches with the MTU set at the default 1500 resulted in a non-burst transfer speed of around 43MB/s (344Mbps).

Repeating the transfer with Jumbo Frames set to 9000 enabled increased this noticeably 53MB/s (424Mbps); a 18.86% increase in write speed.

Given that 53MB/s isn’t that stellar in the first place, this improvement is certainly worth having.