slow copying to TS5810/5800 from Intel Desktop PC RAID 0 arrays

[Kane88]

Have any of you seen this before?  I seem to have found a bug in the Firmware for the Terastation 5810/5000 units.  I've sent in a support request to buffalo tech support.  I hope they will be able to come up with a fix for this.

When I copy files to my Tersatations from a Windows 11 25H2 Intel Desktop PC with a RAID 0 array, the copy goes VERY slow.

With the 5810 it only copies at 45-50MB/sec and with the 5800 only 25-30MB/sec

Current firmware is on both units:  6.08 for the 5810, and 4.20 for the 5800

The TS 5810 has 4 separate RAID0 arrays and are completely blank for testing.

Only one machine has access to the Terastation at a time, it is not an issue of network congestion.

With the 5810 I am using a 2.5gbe switch and the TS 10gbe port
With the 5800 I am using a 1gbe switch and the TS 1gbe port

To rule out other problems out I tried
-copying between two machines that both have RAID 0, and both can copy to each other at 200-250MB/sec no problem.
-and copying to the TS5810 from a PC with a single SATA HDD.  It copies at about 180-200MB/sec or so to the TS 5810, no problem.
-iperf3 tests show everything is happy at about 2.2-2.3gb per second

It is these Intel RAID 0 desktop PCs that the Terastation does not like.  Why do these arrays copy so slow to the Terastation?  It doesn't make sense.  I have recently upgraded to 2.5gb ethernet.  And I can copy at nearly 200-250MB/sec to basically any other device on my 2.5gb network, except for my Terastations.

The PCs I tried are on the same switch as the 5810, and I have tried three different cables (2 cat 5e and 1 cat 6)and three different ports on the switch.  (And FYI cat 5e CAN supposedly handle at least 5gbps and up to 10gbps, and my tests proved it out to work at at least 2.5gbe anyway)

It's not the switch.  It's not the cables.  It's not the PCs.  It's something to do with the Tersastation itself.

The two desktop PCs go through a pair of 2.5gbe switches to each other from two different rooms and are a good 60 ft apart.  They copy to each other just fine at the right speed.  Yet when I go from one of them that is in the same room with the TS 5810 and connected to the SAME switch with 10ft cat 6 cables, I can only get 50MB/sec to the Terastation?  It makes no sense.


Hardware I am using
Two HP Elitedesk 8300 with Realtek 8125 2.5gbe cards + WD 24tb RAID 0 arrays, with the on board network card disabled
One HP Elitedesk 800 G3 with Realtek 8125 2.5gbe card + WD 28tb RAID 0 array, with the on board network card disabled

An HP ProDesk 600 G9 with Realtek 8125 2.5gbe card + Seagate 4tb SATA HDD, with the on board network card disabled

All are Windows 11 Pro 25H2

Separately, I also used the on board intel 1gb ethernet on these machines with the TS 5800, without any 2.5gbe card installed.  And a similar problem.  RAID 0 desktop PCs just don't play nice with these terastations.  If I copy direct from a single hdd of course it will max out at 100MB/sec no problem.


I'm really disappointed that my Terastations are this slow with PCs that use RAID 0 arrays.  The whole point to upgrading to 2.5gbe for me was to get the 10gbe port going with my TS5810 to my PCs that have RAID 0 arrays in them, and put that extra speed to use.



I have a pair of Intel i225 2.5gbe cards on the way to rule out the realtek cards.  Though I do not think the network cards are the problem, because the copy speeds are just fine to each other.

And interestingly- the 800 G3 today even from USB 3.0 is still only copying to the TS5810 at about 50MB/sec

I just do not understand why I need to have a 13th generation i5 PC to write at 2.5gbe speeds to a NAS that is well over 10 years old.  It doesn't make sense.

[Kane88]

So I got a response from Buffalo tech support, and they said to contact Microsoft.  I guess I would expect that somewhat, with an out of warranty unit.

However, since the PCs with RAID 0 arrays in them copy to each other just fine at the right speed:
I don't see Microsoft doing anything about it.  Nor can I afford to pay for a tech support case with them.

So far only my 600 G9 (and I think an HP 6300 maybe?) can copy ok to the TS5810 at the right speed.  And this pc does NOT have an Intel RAID chipset in it.

It is interesting to note that the PCs that have the Intel RAID chipsets in them, are the ones that face this problem.  Even in AHCI single drive mode on the Intel RAID chipsets, the problem still happens on those machines.

I'm thinking about installing the latest RST Rapid Storage drivers but I have not, thinking they may conflict with the Windows OS itself, and in some cases the RST drivers will be much older than what MS is using as a default these days.

I also got a couple of Intel I226-V cards that are 2.5gb, and same thing happened with them.  So I don't think it is so much in the networking hardware.

I am wondering if any of you can duplicate this problem, even with a 5000 series or 3000 series unit, as the 5800 was only copying from or to it at about 30MB/sec.  And I was using various ISOs like Win 11 ISO, or DVD ISOs I made of my movies.  Same data sets copied just fine at the right speed between PCs.

I don't have a Linux PC, but I am wondering if this is an issue copying from NTFS to EXT4 or something else.

I don't know what else to rule out.


It's a real head scratcher.  And hard to believe that the TS5810 10gbe port is reduced to copying at a mere 50 megabytes per second to it, for most of my computers.

[Kane88]

Well, I decided to send in a Windows Feedback request explaining this problem.  I don't expect Microsoft to reply or to do anything about it, but we'll see.

And I tested also an older HP 6300 machine (that doesn't have an Intel desktop raid chipset in it) with the same Realtek 2.5gbe card in it and Win11 25H2.  And sure enough, it copied to the TS 5810 at 250MB/sec!!!

It's crazy that a third gen intel machine (that doesn't have raid) can run circles around an intel 10th generation machine (that has raid), when copying to the Buffalo 5810 NAS.

Honestly, I am surprised this was NOT uncovered during testing of their firmware.  Maybe it's not an issue to a ton of people, but still- this should have been found and rectified.


As for the Buffalo/Linux side, I found this:

https://forums.unraid.net/topic/184182-painfully-slow-smb-transfer-recent-issue/

And this

https://www.reddit.com/r/OpenMediaVault/comments/11gwi1g/significant_samba_speedperformance_improvement_by/


And apparently there IS some sort of issue(s) with Linux Samba shares being slow- in general with RAID arrays.

Do we have any knowledgeable Linux people out here who could assist?  My thought is to try a Live ISO like SysRescueCD to prove some things out, but

1. I don't know how to map samba shares with Linux and
2. I don't know how to make any config changes mentioned in either of these articles linked above.


I also thought of using the Buffalo NAS wiki and maybe trying to load a different os (on a different set of disks), just to prove out the problem resides in the Buffalo Firmware. 


As for Buffalo support, they have 'passed the buck' on to Microsoft for this problem.  Yet I think the issue (even partially) does lie at Buffalo's doorstep given there are issues with slow samba speeds, even for full out Linux users.


The display on the TS 5810 does show it's connected at 2.5gbe.  My link lights show everything is 2.5gbe.  Maybe this slow speed thing isn't an issue to some. But I just find it peculiar to see a 10gbe connection crippled to a whopping 50MB/sec. Just because the client PC simply has an intel raid controller (even when that raid controller is operating in single drive AHCI mode)- it makes- no sense. 

[Kane88]

So now I found this.  And tried the settings in here.  I'm not really big on disabling signing on the Win 11 25H2 PC, but I need to do some testing.  My first quick test copying a 5gb image file FROM the TS 5810 to an Intel RAID 0 array is now at about 216MB/sec

Still, its kind of wierd I need to be editing the registry to make this work.

https://windowsforum.com/threads/fix-slow-network-copy-speeds-in-windows-10-11-by-tuning-smb-and-disabling-throttling.399062/


When I get a chance to test more, I'll post again. 

[Kane88]

So these settings from the article, really do work. 

Fix Slow Network Copy Speeds in Windows 10/11 by Tuning SMB and Disabling Throttling


I also added the robocopy /J switch and wow.  Even copying between terastations (TS 5400+ TS5810) from the 6300 also is up to where it should be, a 95MB/sec average.  I know with this machine that it was definitely at 50MB/sec in the past, without the robocopy /J switch to copy BETWEEN terastations.

I did NOT enable jumbo frames, as the article points out:  Jumbo frames: Only enable jumbo frames if every device on the path supports it correctly (PC NIC + switch + NAS). Misconfigured jumbo frames often reduce performance.

I've seen good results with three machines, the HP 800 G6 10th gen, an HP 800 G3, and also an HP 800 G1.  All three have Intel RAID chipsets and all are copying at at least 200MB/sec now- about 4x higher than what they were beforehand.


So to find out the cause: I went in reverse order:

I started with putting the registry values back to what they were, and then rebooted.  Sure enough, these registry changes had no effect, the copy went ok at the right speed. 

Then, I used powershell to turn SMB encryption back on, and rebooted again. 
And sure enough, there it went back to the way it was.  Slow Copying at 50MB/sec from the Intel HP 800 G3 RAID PC to the TS5810.

So it has been narrowed down to this SMB Require Encryption setting.

And that folks is definitely- THE culprit. 


----------

Now that said, this part here from the article does seem to be something on the buffalo side of things:

SMB encryption: If SMB encryption is enabled on the share, it can heavily tax CPUs. Use it only where needed.
(Kane88: Obviously the share IS the source, which IS the Terastation itself)

Now the questions for the Buffalo Team (if they still read these forums are) are: 

Will they give us options in the future, to change SMB Encryption settings in the Terastation Console?

Why do I need to turn SMB encryption OFF (to get any decent copying speed), simply because I have Intel SATA RAID chipsets in some of my computers? 

Why does the terastation copy ok at the proper speed, with a PC that does not have an Intel SATA RAID chipset?


And please, let's not point fingers completely at Microsoft about this one.

----------


Given that when the SMB encryption setting is on, I can copy between two windows PCs just fine:

I still feel that even partially, this problem resides with the Buffalo firmware / within the Linux OS config they are using.


I am not knowledgeable enough to test this out with Linux.  But given people have had problems with SLOW SMB using things like Open Media Vault, etc that are Linux based:  I assume this SMB encryption problem is universal (to whatever extent in the Linux OS itself), no matter the operating system.


IF SMB encryption indeed is ON in the Terastation 'firmware' (Which I presume it is, yet I have no way to check and verify this, that would require the help of 10... or another Linux or Debian Wizard, who knows how to check that) I could understand why.  Buffalo would want to protect the data of their business customers, first and foremost, which makes senese. 

But as we see here this is done at the cost of decent SMB speed, for some machines.

So you be the judge.  I have some older terastations I might try this out with at some point.  And who knows, maybe this effects the speed of the Linkstations out there too, no idea.


Please note I do not work for buffalo, and you try these settings- at your own risk.  Before you do anything, back up the registry setting beforehand, just as that article says to do!!!  And your mileage may vary, this worked for me, but your configuration and situation, might be different.

-----

Summary
What change was kept in Win11 25H2:
Set-SmbClientConfiguration -RequireSecuritySignature $false


What was tested (it was later removed and reverted back to its default settings)

Back up the registry key

    Press Win + R, type regedit, press Enter.
    Navigate to:
    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Multimedia\SystemProfile
    Right-click SystemProfile → Export (save a .reg file).

Set NetworkThrottlingIndex to "disabled"

    In the same key, find NetworkThrottlingIndex.
        If it doesn't exist: Right-click → New → DWORD (32-bit) Value
    Set its value to:
        Hex: ffffffff
        Decimal: 4294967295
    Click OK.

(Optional) Increase system responsiveness

    In the same location, you may see SystemResponsiveness.
    Some users set it to 0 (decimal) for maximum responsiveness to network tasks.
    If present, set to 10 or 0 based on your use (gaming/streaming vs file server).
    When in doubt, leave it alone.

Reboot

    This change typically requires a reboot to fully apply.

[Kane88]

So on to Checking the TS5810 manual, chapter 3:

https://www.buffalo.jp/s3/guide/ts5010/global/99/en/index.html?Chapter3#h2anc0

There is no information about the SMB section at all.  And no mention of any configuration items for the protocols either.  I went through the rest of the manual, and found nothing.

That information should be right here in Chapter 3.

Buffalo dropped the ball here too.  Why?


So I checked TS 5810 console: File Sharing > SMB
SMB Encryption is set at Default.   But we have no idea what 'default' is, nothing in the manual- says what default is.

Perhaps later, I might try with this setting disabled, and re enabling SMB Encryption on the Windows PC.
But, even if I do that, it will not solve my problem for the 5800 series.


Going to the TS 5800/5400 console: File Sharing > SMB
There are no Settings for SMB Encryption at all.  We have no idea if there is any SMB Encryption or not.  I assume there is, given turning SMB Encryption off on the PC, did make file transfers to the 5800 and 5400 units I have.


So yeah, Buffalo has indeed dropped the ball here somewhat.  I don't think passing the buck to Microsoft solves this one folks, I really don't.