Cannot achieve gigabit speeds

It could be a cable issue. Cable needs to be at least Cat 5e, and even then you should swap out other cables and test to make sure.

I have the same problem, but I use the correct cable.

Maybe someone can help me.

My Problem

same problem since updateing

Add me to the list of people stuck at 100Mbps speeds on a 1000Mbps Ethernet connection...

OMV fully updated on Debian 32bit. Clients on Win10/11. Both sides acknowledge 1000Mbps Ethernet; but transfer speeds locked at ~11MB/s.

RxBrad networking and drivers are controlled by Debian. Debian by now moved to kernel 5.10.60 or later, hence 5.10.0 looks quite outdated to me. Are you sure that the kernel used is receiving & installing patches?

The real end to end read/write performance is influenced by many factors.

While copying a large amount of data, please monitor your system with the dstat command and provide some information about your CPU , RAM and Network load.

And please provide some information about your end to end setup.

E.g.

- How do you access your NAS share? SMB?

- What System are you copying and reading data from? Windows 10?

- What filesystem are you using on your OMV disks?

- What disks in general? (the exact type, as some have a limited write cache which impacts performance heavily when transferring larger amounts of data.).

etc.

Why is this of interest?

Because all these things are in the way of your data being copied from a client to your NAS.

E.g. (I know, this is a simplified description. Bear with me.)

The data gets read by your Windows client from the local disk in NTFS format, then put through your local network adapter in nice chunks of data (according to your network settings like MTU / Frames. Make sure to use jumbo frames), on your NAS the network card receives all these packages and it gets pieced together again to the original data. Then this data runs through your NAS system, the SMB protocol takes it's toll on performance for encoding/decoding, and finally it shall get stored on your disk on the NAS. But as there is different filesystem in place (e.g. ext4 / btrfs / whatever) your data package runs through the cpu again before it finally gets written to the disk. The disk itself receives the package and puts it to its internal write cache. Depending on the size of this cache and the write speed of your disk this can take time again, because if the write cache is full your package needs to "wait" in the system before even getting accepted by the disk. When the disks (e.g. spinning magnetic disks) finally receive the data from the cache it finally gets written.

All these steps in between can affect performance. It is not unusual that you do not get the theoretical full read/write speed that is mathematically possible, when you only look at your disk metrics and the network. Always consider that your data package runs through multiple stacks on both sides of the network, which can heavily affect the real world performance.

I learned this the hard way, as I built a NAS but was only able to write with 14 MB/s to my share from my windows system. Finally my CPU was the bottleneck. It was a multi core system, but the system only used one core for encoding/decoding all the SMB and filesystem stuff, which created a bottleneck there.

So if you want to find your bottleneck you need to look at the full stack your data package is running through and trigger your little Sherlock Holmes to find it.

################################################

Edit: Sorry, it is late, and I have been a bit unclear. When copying over the network using SMB the source and target filesystem on your disks of course has not a big impact. The main impact has the SMB protocol on your cpu, software raid configurations, cache limits of the used disks, MTU / frame setting of your network adapters and the hardware in between (switch and router).

When copying localy from an ext4 disk to a NTFS disk, or vice versa, the NTFS linux driver takes it's toll on the CPU when converting the data. At least on my system (yes, the hardware is not the latest top notch) it only uses one core and puts significant load there creating a bottleneck.

When using the network the bottleneck is again in the CPU but created by the SMB implementation.

I get a satisfying speed out of my setup, but it is not the theoretically maximum possible.