WD My cloud Ex2 Ultra: random poor outgoing performance (max at 100 Mbps)


I have some problem with the performance of my WD EX2 Ultra. Its outgoing traffic (TX) seems max at 100 Mbps. I did several tests:

  • I can use Transmission on the NAS to download at more than 200 Mbps, so the switch and cable is well Gigabit.
  • I can copy from another NAS to my PC at more than 50 MB/s (both are of course connected using Gigabit ethernet).
  • From the NVIDIA Shield, speedtest shows 600 Mbps download, so the connection there is also Gigabit.
  • Both NAS, and my PC and the NVIDIA Shield are in the same LAN (2 different switches but all connected to the same mesh node).
  • When I copy file from the WD My cloud to either my PC or my Shield, the speed is max at 10 MB/s. Actually, occasionnally it starts at 30 MB/s then drop quickly to 10 MB/s then 8 MB/s (maybe some stats problem), sometimes between 5-6 MB/s (I really don’t expect that, nor have any explanation). About the Shield, I don’t have the exact number, but streaming BD at 112 Mbps, there is buffering every few minutes.

I try some settings, like forcing the network interface to 1000 Mbps instead of “Auto”, to no avail. Funnily, I can copy to the NAS steadily at 65 MB/s (so copy a 4 GB file to the NAS takes exactly one minute), but reading from the NAS is much much slower.

PS: the information in the “Device Activity” of the homepage is not reliable. Neither the chart (wrong scale, incorrect Tx). And I’m using the latest firmware 2.31.204.

PS2: I don’t use RAID, and there is not much free space in the HDDs (50 GB in the 2 TB, and 150 GB in the 3 TB, both are 10-year-old WD greens, not the original WD reds).

PS3: After some cleanup, I have now at least 10% free space in each disk, but it hasn’t changed anything.

PS4: I forgot to add that I tried another cable/port in the switch but it didn’t change anything.

PS5: Last night, I freed some space, rebooted but it didn’t change anything as I said in PS3. Then this morning I ssh to look if I can find something.

root@WDEx2Ultra root # ifconfig egiga0
egiga0    Link encap:Ethernet  HWaddr 00:00:C0:1F:74:C5  
          inet addr:  Bcast:  Mask:
          RX packets:58886727 errors:0 dropped:0 overruns:0 frame:0
          TX packets:28140965 errors:0 dropped:127 overruns:0 carrier:0
          collisions:0 txqueuelen:532 
          RX bytes:716166884 (682.9 MiB)  TX bytes:3125327559 (2.9 GiB)

# A few minutes later
root@WDEx2Ultra root # ifconfig egiga0
egiga0    Link encap:Ethernet  HWaddr 00:00:C0:1F:74:C5  
          inet addr:  Bcast:  Mask:
          RX packets:59097759 errors:0 dropped:0 overruns:0 frame:0
          TX packets:28367118 errors:0 dropped:127 overruns:0 carrier:0
          collisions:0 txqueuelen:532 
          RX bytes:868188605 (827.9 MiB)  TX bytes:3439007377 (3.2 GiB)

There is something interesting. The RX packets are 2x more but the RX bytes are 5x less, it’s a 10:1 ratio. The packets/bytes ratio is low because it was night, I guess. That’s why I tried the second time, when there is active download/upload.

New RX packets: 211032 New RX bytes: 152021721 => 720 bytes
New TX packets: 226153 New TX bytes: 313679818 => 1388 bytes, almost max

Well, I’m sad as there is nothing that I can conclude :frowning:

Some more random commands, I don’t know if they are useful…

root@WDEx2Ultra root # netstat -i
Kernel Interface table
docke  1500 0         0      0      0 0           631      0      0      0 BMRU
egiga  1500 0  59531379      0      0 0      28986441      0    127      0 BMRU
egiga  1500 0         0      0      0 0             0      0      0      0 BMRU
egiga  1500 0         0      0      0 0             0      0      0      0 BMRU
lo    65536 0     67277      0      0 0         67277      0      0      0 LRU
root@WDEx2Ultra root # netstat -s
    58997553 total packets received
    0 forwarded
    3161 with unknown protocol
    0 incoming packets discarded
    58994383 incoming packets delivered
    28286419 requests sent out
    2009 ICMP messages received
    323 input ICMP message failed.
    ICMP input histogram:
        destination unreachable: 1738
        timeout in transit: 271
    176 ICMP messages sent
    0 ICMP messages failed
    ICMP output histogram:
        destination unreachable: 176
        InType3: 1738
        InType11: 271
        OutType3: 176
    33049 active connections openings
    6289 passive connection openings
    1402 failed connection attempts
    323 connection resets received
    14 connections established
    50003144 segments received
    112979463 segments send out
    307481 segments retransmited
    2 bad segments received.
    736 resets sent
    8939256 packets received
    176 packets to unknown port received.
    0 packet receive errors
    20172707 packets sent
    0 receive buffer errors
    0 send buffer errors
    29 resets received for embryonic SYN_RECV sockets
    2 packets pruned from receive queue because of socket buffer overrun
    13298 TCP sockets finished time wait in fast timer
    17117 delayed acks sent
    131 delayed acks further delayed because of locked socket
    Quick ack mode was activated 4670 times
    616290 packet headers predicted
    28069045 acknowledgments not containing data payload received
    21356062 predicted acknowledgments
    46270 times recovered from packet loss by selective acknowledgements
    Detected reordering 14 times using FACK
    Detected reordering 55 times using SACK
    Detected reordering 2 times using time stamp
    5 congestion windows fully recovered without slow start
    5 congestion windows partially recovered using Hoe heuristic
    160 congestion windows recovered without slow start by DSACK
    1279 congestion windows recovered without slow start after partial ack
    TCPLostRetransmit: 3827
    813 timeouts after SACK recovery
    190 timeouts in loss state
    265323 fast retransmits
    2938 forward retransmits
    11564 retransmits in slow start
    6442 other TCP timeouts
    TCPLossProbes: 38255
    TCPLossProbeRecovery: 890
    1245 SACK retransmits failed
    2 packets collapsed in receive queue due to low socket buffer
    4928 DSACKs sent for old packets
    8 DSACKs sent for out of order packets
    3321 DSACKs received
    9 DSACKs for out of order packets received
    222 connections reset due to unexpected data
    71 connections reset due to early user close
    1458 connections aborted due to timeout
    TCPDSACKIgnoredOld: 193
    TCPDSACKIgnoredNoUndo: 1118
    TCPSpuriousRTOs: 1272
    TCPSackShifted: 234123
    TCPSackMerged: 183390
    TCPSackShiftFallback: 153644
    TCPDeferAcceptDrop: 2968
    TCPRcvCoalesce: 20360
    TCPOFOQueue: 437
    TCPOFOMerge: 8
    TCPChallengeACK: 53
    TCPSYNChallenge: 51
    TCPSpuriousRtxHostQueues: 229
    InNoRoutes: 9
    InMcastPkts: 54531
    OutMcastPkts: 13632
    InBcastPkts: 53629
    OutBcastPkts: 1250
    InOctets: -1
    OutOctets: -1
    InMcastOctets: 18565321
    OutMcastOctets: 6539619
    InBcastOctets: 6955362
    OutBcastOctets: 144413

PS6: Then actually I’ve found something interesting. It is not the link speed (it helps to dismiss some unlikely hypothesis like 100 Mbps up/1000 Mbps down).

  • When I use scp (copy over ssh): from the NAS: 230 Mbps, to the NAS: 250 Mbps (the speed is steady, CPU around 60% when copy, less than 5% otherwise).
  • Then with FTP: both from and to the NAS at 130-160 Mbps, CPU around 45-65%.

This performance is much less than I expected (FTP performance should be the same as samba). Then I test again with samba.

  • Copy to NAS: between 300-600 Mbps
  • Copy from NAS: steady 650 Mbps (75 MB/s). But WTF? Last night when I tried it was less than 10 MB/s even after a reboot…

I did do several tests last night, when I was watching on my Shield, then went to my office to test with my PC. The performance was always poor. I’ll fix the topic title.