I've added note C.2 in the Post Installation for the RN102/104

Quote

C. [Optional] Post installation

C.1 Boot the RN102/104 with eSATA
C.2 Setup WOL

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Kernel linux-6.14.6-mvebu-370xp-tld-1-bodhi.tar.bz2 package has been uploaded. Please see 1st post for download link.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

bodhi Wrote:
-------------------------------------------------------
> Kernel
> linux-6.14.6-mvebu-370xp-tld-1-bodhi.tar.bz2
> package has been uploaded. Please see 1st post
> for download link.

Kernel installed on RN104, no issue :)

adrien60,

Thanks for the feedback!

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Kernel linux-6.15.2-mvebu-370xp-tld-1-bodhi.tar.bz2 package has been uploaded.

Please see 1st post for download link.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

bodhi Wrote:
-------------------------------------------------------
> Kernel
> linux-6.15.2-mvebu-370xp-tld-1-bodhi.tar.bz2
> package has been uploaded.
>
> Please see 1st post for download link.


Kernel installed without issue :)

adrien60,

Thanks for the feedback!

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

bodhi Wrote:
-------------------------------------------------------
> adrien60,
>
> Thanks for the feedback!


I just updated my RN104 to Debian 13, and it works great.

The only problem I had was with systemd.
In your docs, you tell to add "init=/usr/bin/systemd" to boot args.

It seems that with Debian 13, usr/bin/systemd doesn't exist anymore.
Up to Debian 12 it was a symlink to /lib/systemd/systemd

It works with changing boot args to "init=/lib/systemd/systemd"

> The only problem I had was with systemd.
> In your docs, you tell to add
> "init=/usr/bin/systemd" to boot args.
>
> It seems that with Debian 13, usr/bin/systemd
> doesn't exist anymore.
> Up to Debian 12 it was a symlink to
> /lib/systemd/systemd
>
> It works with changing boot args to
> "init=/lib/systemd/systemd"

Thanks! I've mentioned this somewhere but forgot to modify the release notes.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Kernel linux-6.16.5-mvebu-370xp-tld-1-bodhi.tar.bz2 package has been uploaded.

Please see 1st post for download link.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

bodhi Wrote:
-------------------------------------------------------
> Kernel
> linux-6.16.5-mvebu-370xp-tld-1-bodhi.tar.bz2
> package has been uploaded.
>
> Please see 1st post for download link.

Kernel installed, running OK, thanks

Though 2 minor issues :
- the file is a simple tar, not compressed with bzip2 --> the command "tar xjf" doesn't work, need to use "tar xf"
- inside the archive, the patch file is named with the wrong version : linux-6.15.5-mvebu-370xp-tld-1.patch

adrien60,

Thanks for the feedback!

> Though 2 minor issues :
> - the file is a simple tar, not compressed with
> bzip2 --> the command "tar xjf" doesn't work, need
> to use "tar xf"
> - inside the archive, the patch file is named with
> the wrong version :
> linux-6.15.5-mvebu-370xp-tld-1.patch

Oops! Indeed the copy/paste went wrong... badly. I'll correct the 1st post.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)



Edited 1 time(s). Last edit at 09/10/2025 10:56PM by bodhi.

bodhi,

I tried to use some tool to see my cpu frequency (cpupower frequency-info).

But there is an error :

analyzing CPU 0:
  no or unknown cpufreq driver is active on this CPU
  CPUs which run at the same hardware frequency: Not Available
  CPUs which need to have their frequency coordinated by software: Not Available
  maximum transition latency:  Cannot determine or is not supported.
Not Available
  available cpufreq governors: Not Available
  Unable to determine current policy
  current CPU frequency: Unable to call hardware
  current CPU frequency:  Unable to call to kernel

I looked into cpufreq drivers included in the kernel, and I only see :

root@readynas-104:/lib/modules/5.2.9-mvebu-tld-1# find /lib/modules/$(uname -r) -type f -name '*.ko*' | grep cpufreq
/lib/modules/6.16.5-mvebu-370xp-tld-1/kernel/drivers/cpufreq/armada-37xx-cpufreq.ko.xz
/lib/modules/6.16.5-mvebu-370xp-tld-1/kernel/drivers/cpufreq/cpufreq_ondemand.ko.xz
/lib/modules/6.16.5-mvebu-370xp-tld-1/kernel/drivers/cpufreq/cpufreq_conservative.ko.xz
/lib/modules/6.16.5-mvebu-370xp-tld-1/kernel/drivers/cpufreq/cpufreq_userspace.ko.xz
/lib/modules/6.16.5-mvebu-370xp-tld-1/kernel/drivers/cpufreq/cpufreq_powersave.ko.xz

I tried loading "armada-37xx-cpufreq", but :

root@readynas-104:/lib/modules/5.2.9-mvebu-tld-1# modprobe armada-37xx-cpufreq
modprobe: ERROR: could not insert 'armada_37xx_cpufreq': No such device

Looking into kernel sources, i found out that the cpufreq driver for Armada 370 is "mvebu-cpufreq"
https://github.com/torvalds/linux/blob/v6.16/drivers/cpufreq/mvebu-cpufreq.c

Do you think it could be good to include it in your kernel ?

By the way I looked into your MVEBU kernel targz, and the only cpufreq driver available is also "armada-37xx-cpufreq".

adrien60,

> Looking into kernel sources, i found out that the
> cpufreq driver for Armada 370 is "mvebu-cpufreq"
> https://github.com/torvalds/linux/blob/v6.16/drivers/cpufreq/mvebu-cpufreq.c

> Do you think it could be good to include it in
> your kernel ?

I thought I did, and it was actually in the kernel. But it seems I did not configure it properly. I had no feedback about this until now, thanks!

Will try it in next kernel release.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

bodhi,


> I thought I did, and it was actually in the
> kernel. But it seems I did not configure it
> properly. I had no feedback about this until now,
> thanks!
>
> Will try it in next kernel release.

I'm glad to help finding "bugs" and keep my old NAS alive :)

Maybe the wrong dirver is included because of that in your kernel config file :

CONFIG_ARM_ARMADA_37XX_CPUFREQ=m

I think the variable in the cpufreq Makefile needed for mvebu is "CONFIG_MACH_MVEBU_V7"
https://github.com/torvalds/linux/blob/038d61fd642278bab63ee8ef722c50d10ab01e8f/drivers/cpufreq/Makefile#L70C7-L70C27

All of that are guesses, I'm not an expert in C/Kernel compiling, I'm more into Java/Python/Go...

adrien60,

> CONFIG_ARM_ARMADA_37XX_CPUFREQ=m
>

This is not relevant, it is the module for 64-bit Armada 37xx kernel.

> I think the variable in the cpufreq Makefile
> needed for mvebu is "CONFIG_MACH_MVEBU_V7"
> https://github.com/torvalds/linux/blob/038d61fd642278bab63ee8ef722c50d10ab01e8f/drivers/cpufreq/Makefile#L70C7-L70C27

Yes, it is for Armada XP, and it's already compiled into the kernel currently.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Hello bodhi and Trond,

I was wondering how much transfer speed do you achieve with your ReadyNAS ?

I use SMB between Windows and my NAS (ksmbd on the NAS).

I achieve around 40MB/s in reading from NAS, and 20MB/s writing to the NAS, with an high CPU usage (more than 50%).

I don't remember if it was better at the time my NAS was stock, but I think it is low, especially for writing.

I know I could use other protocols, maybe NFS, but I wonder if it was a specific config on my NAS that could cause a problem.

Here it is my smb config :

root@readynas-104:~# cat /etc/ksmbd/ksmbd.conf    
[global]
        map to guest = bad user
        server smb encrypt = off
        client smb encrypt = off
        strict sync = no
        smb3 encryption = disabled
        server multi channel support = yes
        server signing = disabled

[Private]
        path = /Disque_1/Private
        read only = no
        guest ok = yes
        guest only = yes
        public = yes
        force user = nobody
        browseable = no

Edit : When I copy files between the HDD (data) and the SSD (OS) inside the NAS, I get speed at more than 100MB/s, so this is not the disk which limits



Edited 1 time(s). Last edit at 10/16/2025 08:01PM by adrien60.

adrien,

See these topics in the Wiki thread.

Tuning for low RAM boxes - System and HDD performance.

Increase the vm.min_free_kbytes gradually until you see no more HDD read/write improvement. Test this independently first before looking into Samba.

There is also Samba Tuning, but I think the defaults in later Samba version might be enough.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)



Edited 1 time(s). Last edit at 10/16/2025 08:07PM by bodhi.

Hi bodhi,

I tried changing vm.swappiness and vm.min_free_kbytes and nothing changes.

I see the same "low" performances using SCP/SFTP, so I guess it's not a problem with SMB.

I see a lot of "buffer overrun" erros when I write to the NAS, could this limit the transfer speed ?

[  872.649339] [    C0] mvneta d0074000.ethernet eth1: bad rx status 0f830000 (overrun error), size=576
[  872.712866] [    C0] mvneta d0074000.ethernet eth1: bad rx status 0f830000 (overrun error), size=1088
[  872.773552] [    C0] mvneta d0074000.ethernet eth1: bad rx status 0f830000 (overrun error), size=1088
[  872.838389] [    C0] mvneta d0074000.ethernet eth1: bad rx status 0f830000 (overrun error), size=1088
[  872.878368] [    C0] mvneta d0074000.ethernet eth1: bad rx status 0f830000 (overrun error), size=336

adrien,

> I see a lot of "buffer overrun" erros when I write
> to the NAS, could this limit the transfer speed ?

Definitely. Buffer overrun errors could occur if the flow control are not the same in the client and server.

There are 3 parts in tuning NFS or SMB.

1. Run hdparm and dd tests to measure the hard disk speed. This is where you adjust the vm.min_free_kbytes.

2. Run iperf test to measure network performance. If your network or NIC has problem then it will show.

3. Tune some parameters for NFS and SMB. Debian SMB docs recommend using the default values. But some parameters will help in your particular setup.

Wiki threads

Quote

Perfornance Tuning & Benchmarks

Pogo ProV3 vs Pogo E02
Another Pogo Pro V3 benchmarks
Network performance - SAMBA - NFS (various protocols)
Pogo Pro V3 Network NFS benchmarks
Kirkwood vs OXNAS network performance (with flow control)
Kirkwood vs OXNAS network performance (flow control turned off )
OXNAS vs OXNAS network performance (flow control turned off)
Network Benchmarks for Thecus N2350 (Armada 385) and Zyxel NSA325 (Kirkwood 6820)
Network Benchmarks for Zyxel NSA310S (Kirkwood 6281) and GTI Mirabox (Armada 370)
Samba Tuning
Mount NTFS with big_writes
Increase NFSD max_block_size
Reduce NFSD threads

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)



Edited 2 time(s). Last edit at 10/19/2025 06:27PM by bodhi.

bodhi,

Here are some results about disk and network speed :

HDD speed :
root@readynas-104:~# dd if=/dev/zero of=/Disque_1/test1.img bs=10M count=100 oflag=dsync
100+0 records in
100+0 records out
1048576000 bytes (1.0 GB, 1000 MiB) copied, 24.9101 s, 42.1 MB/s

SSD speed:
root@readynas-104:~# dd if=/dev/zero of=/test1.img bs=10M count=100 oflag=dsync
100+0 records in
100+0 records out
1048576000 bytes (1.0 GB, 1000 MiB) copied, 25.9828 s, 40.4 MB/s

Network speed:
root@wyse5070:~# iperf3 -c 192.168.0.4
Connecting to host 192.168.0.4, port 5201
[  5] local 192.168.0.1 port 55494 connected to 192.168.0.4 port 5201
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec  80.2 MBytes   672 Mbits/sec    0    390 KBytes       
[  5]   1.00-2.00   sec  84.1 MBytes   706 Mbits/sec    0    409 KBytes       
[  5]   2.00-3.00   sec  61.4 MBytes   515 Mbits/sec   17    341 KBytes       
[  5]   3.00-4.00   sec  80.0 MBytes   671 Mbits/sec    0    403 KBytes       
[  5]   4.00-5.00   sec  64.4 MBytes   540 Mbits/sec   21    341 KBytes       
[  5]   5.00-6.00   sec  79.9 MBytes   670 Mbits/sec    0    406 KBytes       
[  5]   6.00-7.00   sec  83.4 MBytes   699 Mbits/sec    0    424 KBytes       
[  5]   7.00-8.00   sec  82.0 MBytes   688 Mbits/sec    0    430 KBytes       
[  5]   8.00-9.00   sec  79.8 MBytes   669 Mbits/sec    0    433 KBytes       
[  5]   9.00-10.00  sec  85.2 MBytes   714 Mbits/sec    0    436 KBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec   780 MBytes   655 Mbits/sec   38            sender
[  5]   0.00-10.01  sec   778 MBytes   652 Mbits/sec                  receiver

Network speed seem to be good.
Disk speed a bit low, but I don't know if we can expect more with a slow CPU

adrien,

root@readynas-104:~# dd if=/dev/zero of=/Disque_1/test1.img bs=10M count=100 oflag=dsync

Should be

dd if=/dev/zero of=/Disque_1/test1.img bs=10M count=100

With that dsync flag, you'd cut the HDD/SSD speed in half. sync option is not realistic.

Also, to maximize speed, the shares should be mounted async,noatime.

> Network speed seem to be good.

In certain setup you could get about 800-900 Mbits/sec (if the flow control is off, and boxes in the local network are about the same as this).

This CPU is not slow but it does not use hardware buffer. So yes if you got 700 Mbits/sec then it is decent.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

bodhi,

I remounted my HDD with "async,noatime", and removed dsync flag, here are the results :

root@readynas-104:~# dd if=/dev/zero of=/Disque_1/test1.img bs=10M count=100
100+0 records in
100+0 records out
1048576000 bytes (1.0 GB, 1000 MiB) copied, 14.4151 s, 72.7 MB/s
root@readynas-104:~# dd if=/dev/zero of=/test1.img bs=10M count=100
100+0 records in
100+0 records out
1048576000 bytes (1.0 GB, 1000 MiB) copied, 24.4221 s, 42.9 MB/s
root@readynas-104:~# cat /etc/fstab 
# /etc/fstab: static file system information.
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
LABEL=rootfs    /               ext3    noatime,errors=remount-ro 0 1
tmpfs          /tmp            tmpfs   defaults          0       0
UUID=96f54254-cfdd-4de1-8fb7-266a1946011e /Disque_1 ext4 defaults,nofail,async,noatime  0      2
# a swapfile is not a swap partition, no line here
#   use  dphys-swapfile swap[on|off]  for that

The HDD is faster now, but nothing changed for the SSD.
It doesn't changed the speed of SMB transfer.

adrien,

> root@readynas-104:~# dd if=/dev/zero
> of=/Disque_1/test1.img bs=10M count=100
> 100+0 records in
> 100+0 records out
> 1048576000 bytes (1.0 GB, 1000 MiB) copied,
> 14.4151 s, 72.7 MB/s

That's more like it. In the ball park.

Please post the output of these commands:

dmesg | grep -i ata
ethtool eth0
mount
sysctl -a | grep -iE 'free|swap'
swapon

When you test NFS or SMB, the first thing to do is to pull files from the share to see the read performance. I wonder what that is?

This SoC does not have HW buffer for networking. But the CPU is plenty fast and support Gbits easily.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)



Edited 1 time(s). Last edit at 10/19/2025 06:29PM by bodhi.

And also test both raw speed read for both disks

hdparm -Tt /dev/sda
hdparm -Tt /dev/sdb

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)



Edited 1 time(s). Last edit at 10/19/2025 06:32PM by bodhi.

bodhi,

here are the results of commands :

root@readynas-104:~# dmesg | grep -i ata
[    0.000000] [    T0] CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache
[    0.000000] [    T0] Memory policy: Data cache writeback
[    0.000000] [    T0] printk: log buffer data + meta data: 131072 + 409600 = 540672 bytes
[    0.115942] [    T1] Memory: 489068K/524288K available (10240K kernel code, 822K rwdata, 3436K rodata, 1024K init, 451K bss, 33980K reserved, 0K cma-reserved, 0K highmem)
[    1.144683] [    T1] libata version 3.00 loaded.
[    3.324463] [    T1] ahci 0000:02:00.0: AHCI vers 0001.0000, 32 command slots, 6 Gbps, SATA mode
[    3.374244] [    T1] ata1: SATA max UDMA/133 abar m2048@0xf8110000 port 0xf8110100 irq 32 lpm-pol 0 ext
[    3.383030] [    T1] ata2: SATA max UDMA/133 abar m2048@0xf8110000 port 0xf8110180 irq 32 lpm-pol 0 ext
[    3.391719] [    T1] ata3: SATA max UDMA/133 abar m2048@0xf8110000 port 0xf8110200 irq 32 lpm-pol 0 ext
[    3.400352] [    T1] ata4: SATA max UDMA/133 abar m2048@0xf8110000 port 0xf8110280 irq 32 lpm-pol 0 ext
[    3.411565] [    T1] sata_mv d00a0000.sata: slots 32 ports 1
[    3.419832] [    T1] scsi host4: sata_mv
[    3.424241] [    T1] ata5: SATA max UDMA/133 irq 33 lpm-pol 0
[    3.733116] [  T706] ata2: SATA link down (SStatus 0 SControl 300)
[    3.738868] [  T711] ata3: SATA link down (SStatus 0 SControl 300)
[    3.751974] [  T730] ata5: SATA link down (SStatus 0 SControl F300)
[    3.903352] [  T701] ata1: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[    3.916355] [  T701] ata1.00: ATA-9: Patriot P210 128GB, W0714A0, max UDMA/133
[    3.926246] [  T716] ata4: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[    3.933104] [  T701] ata1.00: 250069680 sectors, multi 1: LBA48 NCQ (depth 32), AA
[    3.948237] [  T716] ata4.00: ATA-8: SAMSUNG HD103SJ, 1AJ10001, max UDMA/133
[    3.961413] [  T716] ata4.00: 1953525168 sectors, multi 0: LBA48 NCQ (depth 32), AA
[    3.986328] [  T701] ata1.00: configured for UDMA/133
[    3.991341] [  T716] ata4.00: configured for UDMA/133
[    4.003839] [   T39] scsi 0:0:0:0: Direct-Access     ATA      Patriot P210 128 4A0  PQ: 0 ANSI: 5
[    4.043221] [   T47] scsi 3:0:0:0: Direct-Access     ATA      SAMSUNG HD103SJ  0001 PQ: 0 ANSI: 5
[   19.658958] [ T1316] EXT4-fs (sda1): mounted filesystem 9569476a-a153-4a4b-b8b2-a03a01d4d20a ro with ordered data mode. Quota mode: none.
[   26.548087] [    T1] systemd[1]: systemd-hwdb-update.service - Rebuild Hardware Database was skipped because of an unmet condition check (ConditionNeedsUpdate=/etc).
[   46.622696] [ T1548] EXT4-fs (sdb1): mounted filesystem 96f54254-cfdd-4de1-8fb7-266a1946011e r/w with ordered data mode. Quota mode: none.
root@readynas-104:~# ethtool eth1
Settings for eth1:
        Supported ports: [ TP    MII ]
        Supported link modes:   10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Full
        Supported pause frame use: Symmetric
        Supports auto-negotiation: Yes
        Supported FEC modes: Not reported
        Advertised link modes:  10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Full
        Advertised pause frame use: Symmetric
        Advertised auto-negotiation: Yes
        Advertised FEC modes: Not reported
        Link partner advertised link modes:  10baseT/Half 10baseT/Full
                                             100baseT/Half 100baseT/Full
                                             1000baseT/Full
        Link partner advertised pause frame use: Symmetric
        Link partner advertised auto-negotiation: Yes
        Link partner advertised FEC modes: Not reported
        Speed: 1000Mb/s
        Duplex: Full
        Auto-negotiation: on
        Port: Twisted Pair
        PHYAD: 1
        Transceiver: external
        MDI-X: on
        Supports Wake-on: pg
        Wake-on: g
        Link detected: yes
root@readynas-104:~# mount
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
udev on /dev type devtmpfs (rw,nosuid,relatime,size=245152k,nr_inodes=61288,mode=755)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=600,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nosuid,nodev,noexec,relatime,size=50124k,mode=755)
/dev/sda1 on / type ext3 (rw,noatime,errors=remount-ro)
securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
cgroup2 on /sys/fs/cgroup type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate,memory_recursiveprot)
bpf on /sys/fs/bpf type bpf (rw,nosuid,nodev,noexec,relatime,mode=700)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=36,pgrp=1,timeout=0,minproto=5,maxproto=5,direct)
mqueue on /dev/mqueue type mqueue (rw,nosuid,nodev,noexec,relatime)
tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k)
debugfs on /sys/kernel/debug type debugfs (rw,nosuid,nodev,noexec,relatime)
tmpfs on /run/credentials/systemd-journald.service type tmpfs (ro,nosuid,nodev,noexec,relatime,nosymfollow,size=1024k,nr_inodes=1024,mode=700,noswap)
fusectl on /sys/fs/fuse/connections type fusectl (rw,nosuid,nodev,noexec,relatime)
configfs on /sys/kernel/config type configfs (rw,nosuid,nodev,noexec,relatime)
tmpfs on /run/credentials/systemd-resolved.service type tmpfs (ro,nosuid,nodev,noexec,relatime,nosymfollow,size=1024k,nr_inodes=1024,mode=700,noswap)
tmpfs on /tmp type tmpfs (rw,relatime)
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,nosuid,nodev,noexec,relatime)
/dev/sdb1 on /Disque_1 type ext4 (rw,noatime)
tmpfs on /run/credentials/getty@tty1.service type tmpfs (ro,nosuid,nodev,noexec,relatime,nosymfollow,size=1024k,nr_inodes=1024,mode=700,noswap)
tmpfs on /run/credentials/serial-getty@ttyS0.service type tmpfs (ro,nosuid,nodev,noexec,relatime,nosymfollow,size=1024k,nr_inodes=1024,mode=700,noswap)
root@readynas-104:~# sysctl -a | grep -iE 'free|swap'
fs.quota.free_dquots = 0
vm.min_free_kbytes = 131072
vm.swappiness = 1
root@readynas-104:~# swapon
NAME      TYPE SIZE USED PRIO
/var/swap file 1.9G   8K   -2

When I read data from the NAS with SMB share (NAS->Windows), I get about 40~42MB/s which is not so bad
When I write data to the NAS with MSB (Windows -> NAS), I get about 20MB/s

I can notice a big CPU usage by ksmbd in both cases (nearly 80%)

I tried SFTP, but speed is much much lower, like 7MB/s in RX and TX

Edit : hdparm tests :

root@readynas-104:~# hdparm -Tt /dev/sda

/dev/sda:
 Timing cached reads:   790 MB in  2.00 seconds = 394.32 MB/sec
 Timing buffered disk reads: 338 MB in  3.00 seconds = 112.58 MB/sec
root@readynas-104:~# hdparm -Tt /dev/sdb

/dev/sdb:
 Timing cached reads:   754 MB in  2.00 seconds = 376.41 MB/sec
 Timing buffered disk reads: 312 MB in  3.04 seconds = 102.51 MB/sec

Edited 1 time(s). Last edit at 10/19/2025 06:41PM by adrien60.

adrien,

> root@readynas-104:~# dmesg | grep -i ata

Everything looks normal. Does your SDD have cache, how big?

> root@readynas-104:~# ethtool eth1

> Advertised pause frame use: Symmetric
> Link partner advertised pause frame use: Symmetric

Looks like flow control is enabled, that will slow down the xfer.

dmesg | grep flow

Unless you have a lot of network buffer overruns, I would turn flow control off.

> When I read data from the NAS with SMB share
> (NAS->Windows), I get about 40~42MB/s which is not
> so bad
> When I write data to the NAS with MSB (Windows ->
> NAS), I get about 20MB/s
>
> I can notice a big CPU usage by ksmbd in both
> cases (nearly 80%)

Yes. SMB is slow and hard to tune. There are many variables. I always avoid pushing files to the Linux NAS using SMB. Especially the NAS we are using here are low in horsepower and RAM.

Can you set up NFS on the Window box? I recall rayknight mentioned that NFS4 is supported now in Windows 10 or 11.

> root@readynas-104:~# hdparm -Tt /dev/sda
>
> /dev/sda:
> Timing cached reads: 790 MB in 2.00 seconds =
> 394.32 MB/sec
> Timing buffered disk reads: 338 MB in 3.00
> seconds = 112.58 MB/sec
> root@readynas-104:~# hdparm -Tt /dev/sdb
>
> /dev/sdb:
> Timing cached reads: 754 MB in 2.00 seconds =
> 376.41 MB/sec
> Timing buffered disk reads: 312 MB in 3.04
> seconds = 102.51 MB/sec
> [/code]

Looks good!

So now you've confirmed that the HDD/SSD speed and network performance are OK.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

bodhi,

My SSD doesn't have cache, it is a Patriot P120 which has no DRAM cache.

root@readynas-104:~# dmesg | grep flow
[   51.415725] [  T116] mvneta d0074000.ethernet eth1: Link is Up - 1Gbps/Full - flow control rx/tx

I already tried disabling flow control, it doesn't change, I have lot of buffer overrun errors with flow control enabled or disabled.
I don't have any buffer overrun errors while I do iperf tests, I don't know if this is relevant.

I'll try to setup NFS server on NAS and Windows as NFS client.

To check, I tried reinstalling stock OS on a spare old HDD (slower HDD, as it is a 2.5" 5400rpm from an old laptop)
I got surprising results : 65~70MB/s writing to NAS, 35MB/s reading from NAS.

I know that we can't really compare, as it is an old OS (Debian 8), and different filesystem (BTRFS), but write speed was way better.

Edit :
I set up a NFS server on the NAS.
I get same read/write speeds as with SMB.

Edit 2:
I tried with a USB/Ethernet adapter, it's worse, 20MB/s in rx and tx.
But no buffer overrun errors

Do you think it could be because of OS (Debian 13, Systemd), and I should try reinstalling from your rootfs ?



Edited 3 time(s). Last edit at 10/20/2025 06:32PM by adrien60.

adrien,

> My SSD doesn't have cache, it is a Patriot P120
> which has no DRAM cache.

So it's good for rootfs (where mostly random read/writes occur), but not for network share (where most sequential read/writes occur).

> I already tried disabling flow control, it doesn't
> change, I have lot of buffer overrun errors with
> flow control enabled or disabled.
> I don't have any buffer overrun errors while I do
> iperf tests, I don't know if this is relevant.

iperf tests only confirm the potential network speed, but not a realistic measurements for what's going on in real life.

> To check, I tried reinstalling stock OS on a spare
> old HDD (slower HDD, as it is a 2.5" 5400rpm from
> an old laptop)
> I got surprising results : 65~70MB/s writing to
> NAS, 35MB/s reading from NAS.

The vendor kernel and rootfs have a lot of tweaks.

> Edit 2:
> I tried with a USB/Ethernet adapter, it's worse,
> 20MB/s in rx and tx.
> But no buffer overrun errors

Yes. USB Ethernet is very slow even when they claim Gbps. The USB bus is a bottleneck.

> Do you think it could be because of OS (Debian 13,
> Systemd), and I should try reinstalling from your
> rootfs ?

It's worth a try. You can create a brand new USB rootfs and run that with your HDD as network storage. Use a swap file on the HDD. And change the vm.min_free_kbytes like you did. And turn off flow control.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

bodhi,

I tried going back to 6.6.2 rootsfs with 6.16.5 kernel, with or without systemd, same results.

But, the only thing I didn't try, is moving back from ksmbd to smbd....

And then :
- Speed is 30~32MB/s both ways
- No more buffer overrun errors

I guess I won't try more, and I'll stay like that, as it is a spare NAS.

Maybe you're right and stock OS has a lot of tweaks to make this low power NAS as fast as possible, to make customers happy :)
Though I don't think it's a good thing, as tweaks aren't easy to maintain if you want to keep OS up to date.

Thanks for all you help !