Oxnas (Medion) Samba speed to slow

I have flashed my Medion NAS according to wiki:

Everything works perfectly. Unfortunately the samba speed is not fast enough. With the original Medion firmware (smbV1) I copy between NAS <-> Win11 over Samba ~70MB/s. Now it is about ~10MB/s.

My approaches:

  • SATA is too slow?
  • gigabit or 100 Mbit?
  • Ethernet driver


  • other openWRT versions 19.x-22.x
  • In the luci GUI I have activated the samba tweaks
  • flowcontrol deactivated with "ethtool -A eth0 rx off tx off"

Does anyone have the same problem and maybe could solve it?

Here are my facts:

Medions NAS:      86517.01
Model:            MitraStar Technology Corp. STG-212
Architecture:     ARMv6-compatible processor rev 5 (v6l)
Platform:         oxnas/ox820
Firmware version: OpenWrt 21.02.5 (more versions tested)
Ethernet:         RTL8211E Gigabit Ethernet
HDD:              org. SATA 1TB (tests with 2TB with write crashes)

ethtool eth0

root@ChrisNAS:~# ethtool eth0
Settings for eth0:
        Supported ports: [ TP MII ]
        Supported link modes:   10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Half 1000baseT/Full
        Supported pause frame use: Symmetric Receive-only
        Supports auto-negotiation: Yes
        Supported FEC modes: Not reported
        Advertised link modes:  10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Half 1000baseT/Full
        Advertised pause frame use: Symmetric Receive-only
        Advertised auto-negotiation: Yes
        Advertised FEC modes: Not reported
        Link partner advertised link modes:  10baseT/Half 10baseT/Full
                                             100baseT/Half 100baseT/Full
        Link partner advertised pause frame use: Symmetric Receive-only
        Link partner advertised auto-negotiation: Yes
        Link partner advertised FEC modes: Not reported
        Speed: 1000Mb/s
        Duplex: Full
        Port: MII
        PHYAD: 0
        Transceiver: external
        Auto-negotiation: on
        Supports Wake-on: ug
        Wake-on: d
        Current message level: 0x0000003f (63)
                               drv probe link timer ifdown ifup
        Link detected: yes

iperf tcp

root@ChrisNAS:~# iperf -c -p 4711 -t 30 -i 10
Client connecting to, TCP port 4711
TCP window size:  241 KByte (default)
[  3] local port 54524 connected with port 4711
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec   405 MBytes   340 Mbits/sec
[  3] 10.0-20.0 sec   441 MBytes   370 Mbits/sec
[  3] 20.0-30.0 sec   437 MBytes   366 Mbits/sec
[  3]  0.0-30.0 sec  1.25 GBytes   359 Mbits/sec

iperf udp

root@ChrisNAS:~# iperf -c -u -b 1000m -t 30 -i 10
Client connecting to, UDP port 5001
Sending 1470 byte datagrams, IPG target: 11.76 us (kalman adjust)
UDP buffer size:  176 KByte (default)
[  3] local port 33543 connected with port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec   125 MBytes   105 Mbits/sec
[  3] 10.0-20.0 sec   106 MBytes  89.1 Mbits/sec
[  3] 20.0-30.0 sec   103 MBytes  86.5 Mbits/sec
[  3] WARNING: did not receive ack of last datagram after 10 tries.
[  3]  0.0-30.0 sec   334 MBytes  93.4 Mbits/sec
[  3] Sent 238214 datagrams

The stock Samba was over-optimized, causing data corruption under certain circumstances. (https://bugzilla.samba.org/show_bug.cgi?id=10584). As this will not be the case in OpenWrt Samba, 70MB/sec is unrealistic.
But 10MB/sec is slow. Have you looked at the CPU usage during speed test?

over 80%. Could this be the problem? Is there anything that can be done?

Could try kmsbd instead.

I try ksmbd.
From the feeling a little faster :wink:
However, both cores are 100% utilized as soon as the file transfer starts.

I read that you can turn off the Samba compression. But I can't find anything in the Samba documentation.

Any other ideas?

Your iperf measurements would suggest that your device in its current state taps out just saturating the link long before you come anywhere close to your expected 70 MB/s of SMB throughput. Also what I find odd is that aftermarket binary named "udpspeeder", which is clearly intended to influence networking on some level, and judging from your UDP iperf results very heavily so. I would probably take the device back to pure stock OpenWrt and see if it makes any difference.

I am aware that I do not get full gigabit speed with this crappy NAS. But 60-70 Mbit/s has I when copying with the original Medion firmware always. But this supports only SMB v1.
My problem is that I can't get the iperf speed with samba (44MB/s).

iperf was recorded with a pure openWRT. udpspeeder was only on it for a short time for testing purposes, but it did not make any difference.

Does anyone know anything about Samba compression?

i did a dd test came up with this:

root@ChrisNAS:~# dd if=/dev/zero of=/mnt/sda2/somefile
^C7562937+0 records in
7562937+0 records out
3872223744 bytes (3.9 GB, 3.6 GiB) copied, 745.303 s, 5.2 MB/s

If I understand correctly, that is the problem, isn't it?

How do you get

SMB performance if dd itself, i.e. nothing between the system and the hard drive, is only able to do 5 MB/s? This doesn't add up.

Of course you won't, as long as you're CPU limited you will never get anything close to iperf speed with an actual service using CPU time.

Here my knowledge is not enough. I can only interpret the values that the programs give me. I hope here in the community there is the knowledge

dd tells me it copies files with 5 mbit/s, this is clearly too slow. CPU Usage say this:

windows tells me at the same instance (now i test the parameter smb encypt = off in smb.conf)

iperf tells me also same instance

root@ChrisNAS:~# iperf -c -p 4711 -t 30 -i 10
[  3]  0.0-30.0 sec  1.24 GBytes   356 Mbits/sec

Now tell me, where is the Bottleneck? And where is the failure?

You realize that this is a keyword on CPU limited systems? SMB v1 had much weaker (broken) encryption requirements than SMB v3, for which the CPU has to work much harder.

I understand it. But this is not the problem that dd copy with 5 mbit/s.

If you have local copy performance issues then examine your drive partitioning, alignment and partition format.

For low perf cpu you want everything to be as basic as possible. 1 partition, correct alignment, ext3

And test the drive on another system to see if it is faulty

Your dd copy was not 5mbit/s, but 5MByte/s. That is a factor 8 in difference, assuming you didn't mean millibit.
The dd copy wasn't applied well. This way it wrote a sequence of 512 bytes. which doesn't fit well with 4k sectors/clusters.
Better use bigger blocks:

dd if=/dev/zero of=/mnt/sda2/somefile bs=1M
1 Like

@snickerweb USB3 or SATA3 port for external disk?

Hi Mijzelf, is correct, the large block is faster. But isn't that still much too little? Or do I have to calculate it twice, because it reads and writes on the same disk?

No, not twice. /dev/zero is not the harddisk, it's a pseudo device.
Are you sure the stock firmware did 70MB/sec, and not 70Mbit/sec? The network interface nor the disk can handle that speed in OpenWrt, and Samba is CPU limited at 15MB/sec.

Encryption is expensive. So as long as the CPU is the bottleneck, avoid encrytion.

Heise.de tested the original firmware

with jumbo frames Read 83 MByte Write 56 MByte/s.

Without Jumbo-Frames 78/37 MByte/s

How I can use jumbo frames with openWRT?

It's a potato by todays standards, Samba 4.x is a more intensive and can pretty much satuerate gbit links on hardware that isn't ancient. ARMv6 is considered "dead" since several years and people have moved on. You might get better performance using the kernel module but the hardware is very old and have quirks that don't help performance. It's a classic case of can't fix.

I have now installed Debian. Out of the box 1.5x speed read/write. So there is still something to get out. I'll continue testing. :smiling_face:
Which possibilities besides Samba do I have to transfer data to Win11? FTP is not so smoothly integrated in Windows.
Let's see what works with NFS. And if I can find a decent NFS driver for Windows.