PopOS vs Windows. Slower transfer speeds in general

[Mr_Whom]

Hi guys.

Just a simple (or perhaps, complicated?) question.

I’ve noticed, that still to this date, there is some performance “issues” when it comes to file transfers in Debian based OS’.
What I mean is:

I can copy a big file in Windows to my QNas and it will transfer stable at 112 Mb/s. But when that same file is copied in PopOS to the NAS, it will run stable at 83 Mb/s.
At first I assumed it was the same old “SMB be slow” thing. But now I am not so sure.

In PopOS, If I copy the same file from the NVMe drive that both PopOS and Windows 10 is located on, onto another NVMe drive formated with NTFS, PopOS will only copy with 336 Mb/s. Windows Will do 982 Mb/s. The second NVMe drive goes through the chipset, the OS drive goes directly to the CPU.

Is this a question of NT filesystems, or is there more to it?

The system is a x570 chipset with a 5800x CPU. So I wouldn’t think it’s a hardware bottleneck in the case of SMB networking.
Is it driver related?

If anyone have an input to this, I would appreciate it.

[cakeisamadeupdrug]

Silly question, but this isn’t a conversion thing with Windows measuring in Mb/s and PopOS measuring in Mib/s, is it?

[TheCakeIsNaOH]

@Mr_Whom

Is this a question of NT filesystems, or is there more to it?

The current ntfs driver that most Linux distros use (ntfs-3g) is single threaded and not efficient. Basically, you are almost certainly being bottlenecked by the linux ntfs support.

@Mr_Whom

I can copy a big file in Windows to my QNas and it will transfer stable at 112 Mb/s. But when that same file is copied in PopOS to the NAS, it will run stable at 83 Mb/s.
At first I assumed it was the same old “SMB be slow” thing.

Are you sure that the connection is using the newest version of the SMB protocol that both ends support?

[Mr_Whom]

@cakeisamadeupdrug

Silly question, but this isn’t a conversion thing with Windows measuring in Mb/s and PopOS measuring in Mib/s, is it?

I was thinking the same thing at some point. But it doesn’t seem to be the case.

[Mr_Whom]

@TheCakeIsNaOH

The current ntfs driver that most Linux distros use (ntfs-3g) is single threaded and not efficient. Basically, you are almost certainly being bottlenecked by the linux ntfs support.

I might be wrong, but I just have a hard time understanding how the would be no difference in speeds between a 1700X and a 5800X, if it came down to single threaded performance alone.
Also. My old Qnap can run deliver and receive the mentioned 112Mb/s without any trouble, despite being a slow CPU and running “linux”.

I just checked the version of SMB my Qnap was running. to my surprise it was only running SMB 2.1 and was allowed to go down to SMB 1.0 if needed.

I’ve set it to go between SMB 3 and SMB 2.1. I will report back with the results.

[Exard3k]

If you can test this with an NFS share, you can rule out any SMB-related problems.

[Brutkruemel]

I’ve recently dealt with a similar thing.
So maybe this will help.
How are you mounting the share on linux?
If it’s through the GUI-file explorer thing i discovered there is a great performance hit. It does not mount it “correctly”. But i do not know the technical details why.
Mount the share via CLI

sudo mount -t cifs -o username=serverUserName,gid=...,uid=...  //myServerIpAdress/sharename /MyFolder

Then try transfer speeds again with that mounting.
For me that solved it.

[thro]

Don’t use NTFS in Linux.

It works barely but it’s certainly not ideal and as above its definitely not optimised.

[TheCakeIsNaOH]

@Mr_Whom

I might be wrong, but I just have a hard time understanding how the would be no difference in speeds between a 1700X and a 5800X, if it came down to single threaded performance alone.
Also. My old Qnap can run deliver and receive the mentioned 112Mb/s without any trouble, despite being a slow CPU and running “linux”.

The speed issue with ntfs-3g should only affect ntfs filesystems, and should have no effect on your network drive.

[Mr_Whom]

I forced everything to run Samba 3.0. This improved the speeds from 83/88 to 97+ Mb/s. Now we are in MiB contra MB territory.

[Mr_Whom]

@Brutkruemel

sudo mount -t cifs -o username=serverUserName,gid=...,uid=...  //myServerIpAdress/sharename /MyFolder

I tried to mount the CIF this way. It wouldn’t play along. Surely because of faults of my own.

[Mr_Whom]

@Exard3k

If you can test this with an NFS share, you can rule out any SMB-related problems.

I was tinkering with a NFS share on the Qnap NAS. It seem to get messy because of the mixed ways of granting user permissions to the same folder. Qnap also only wanted to manage NFS permissions via host and IPs etc?

[Brutkruemel]

What was the problem? Did it not mount?

You can get the uid and gid on you PC from the CLI command

id

so the the final command should look something like this e.g.:

sudo mount -t cifs -o username=brutkruemel,uid=1000,gid=1001 //192.168.1.23/ShareName /home/brutkruemel/mountfolder

[Mr_Whom]

@Brutkruemel

What was the problem? Did it not mount?

You can get the uid and gid on you PC from the CLI command

First of, it think everything is a bad mount.
I want to be honest with you here. I am flat on energy, and I am starting to get irritated at what I personally persive as being oddly complicated way of sharing files. At least samba work with a simple user list with groups and assigned privileges.

It’s likely NFS is no more complicated, but it seems odd to me on the Qnap server.

In other words. I have no idea how NFS works and I don’t have the mental energy and capacity to fight with it right now.