Your benchmark is a samba file transfer?
Maybe the network is fine and its only samba, that is slow.
Try iperf to test your speed.
Thanks @Monarc
Correct as that’s what I will generally use for file transfers. As I’ve said previously, it works fine in a Linux Mint install, but not on Manjaro. Just for shits’n’giggles I tried Manjaro Cinnamon just to see if it might have something to do with the desktop environment (as mint used cinnamon) but still slow in that too.
With iperf, am I correct that I need to start it on the server I’m testing?
iperf -s
Then start it on my laptop with Manjaro
iperf -c ip-address
I’ll have to lookup how to start it on my QNAP as I don’t think it has a terminal installed natively. I have tried to connect to it via ssh but doesn’t want to connect for some reason. I’ll have to read up on that a bit more.
Thanks @Monarc
So I managed to run the iperf test between my laptop and the QNAP server in two separate terminals. This is what was output (although I’ve blanked the IP address and just left the ports and last digit):
from iperf -s
[ 4] local xxx.xxx.xxx.4 port 5001 connected with xxx.xxx.xxx.17 port 47840
[ ID] Interval Transfer Bandwidth
[ 4] 0.0-10.0 sec 1.10 GBytes 941 Mbits/sec
and iperf -c
[ 3] local xxx.xxx.xxx.17 port 47840 connected with xxx.xxx.xxx.4 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.0 sec 1.10 GBytes 943 Mbits/sec
This appears to confirm there’s nothing wrong with the network (as before, it works fine on windows and other linux distros). So there’s something wrong with the way the samba connection is configured in Manjaro perhaps?
Could you look, how the share is mounted?
simply type
mount
and look for the line for your samba share. Which version you it use? e.g.
(the options)
and the cifs module for it, is part of the kernel, you could try the newest kernel. But i think it a config problem.
Thanks @Monarc
I typed mount and it spat out this
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
sys on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
dev on /dev type devtmpfs (rw,nosuid,relatime,size=7780640k,nr_inodes=1945160,mode=755)
run on /run type tmpfs (rw,nosuid,nodev,relatime,mode=755)
efivarfs on /sys/firmware/efi/efivars type efivarfs (rw,nosuid,nodev,noexec,relatime)
/dev/sda2 on / type ext4 (rw,noatime)
securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
cgroup2 on /sys/fs/cgroup type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate)
pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime)
none 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=30,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=11927)
hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime,pagesize=2M)
mqueue on /dev/mqueue type mqueue (rw,nosuid,nodev,noexec,relatime)
debugfs on /sys/kernel/debug type debugfs (rw,nosuid,nodev,noexec,relatime)
tracefs on /sys/kernel/tracing type tracefs (rw,nosuid,nodev,noexec,relatime)
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,nosuid,nodev,noexec,relatime)
configfs on /sys/kernel/config type configfs (rw,nosuid,nodev,noexec,relatime)
fusectl on /sys/fs/fuse/connections type fusectl (rw,nosuid,nodev,noexec,relatime)
/dev/sda1 on /boot/efi type vfat (rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro)
tmpfs on /tmp type tmpfs (rw,noatime)
tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,size=1557580k,nr_inodes=389395,mode=700,uid=1000,gid=1000)
gvfsd-fuse on /run/user/1000/gvfs type fuse.gvfsd-fuse (rw,nosuid,nodev,relatime,user_id=1000,group_id=1000)
portal on /run/user/1000/doc type fuse.portal (rw,nosuid,nodev,relatime,user_id=1000,group_id=1000)
I can’t see anything here that even looks like where it is mounted. But I’ve mounted it though Nemo file manager. And no reference to CIFS either
I’ve done some playing around the last few days.
I re-read another post with similar issues to mine now I could actually follow what was going on Slow internet in fresh install - #30 by megavolt
I had a look at other distros network settings top see what was different. I noticed in the ones that transferred at higher speeds had their Link Negotiations set to Ignore. I tried that with mine, still transfers at 20MB/s.
I tried manually setting the link negotiation to 1Gb/s but still slow.
I tried unmounting the NAS and reconnecting when changing the settings and also rebooting incase but still 20MB/s transfer.
I gave Endeavour OS a go as well as it’s Arch based too as all the Debian based distro’s I tried transferred with no problems. And no problems with Endeavour OS transferring files at about 80MB/s also.
Any other things I might be able to try?
So a little more playing and digging around with mounts, I used
sudo mount -t cifs //ip-address/multimedia /mnt/QNAPmultimedia -o username=xxxxx,password=xxxx
to mount the volume under a mount I created QNAPmultimedia
Now when I run the “mount” command it shows the following
//ip-address/multimedia on /mnt/QNAPmultimedia type cifs (rw,relatime,vers=2.1,cache=strict,username=schmidtp,uid=0,noforceuid,gid=0,noforcegid,addr=ip-address,file_mode=0755,dir_mode=0755,soft,nounix,serverino,mapposix,rsize=1048576,wsize=1048576,bsize=1048576,echo_interval=60,actimeo=1)
The mount itself doesn’t show up in the file manager (Nemo), but does in dolphon. However if I go to
/mnt/QNAPmultimedia my files on the server show up. And the files transfer at about 80-90MB/s (as they should be)!
But it still begs the question why, when you mount your shares through the file manager it’s extremely slow? I assume they should be doing something similar?
I’m assuming, and thus know I might be wrong, it’s something to do with virtualization/emmulation vs direct kernel interaction. I think.
While cifs/smb is direct kernel implementation and interaction, it has to be virtualised and emulated if you mount it through Thunar. Or any Userland/indirect method. Because it’s virtualo/emmulated it takes much more resources to accomplish the same thing. So it’ll be slower, just as anything virtualized/emmulated is.
Or, anyway, that’s how I see it.
Thanks. After watching some Youtube and a few how to’s and consulting that very Wiki , I ended up using systemd commands to mount all the NAS drives. Other than noticing even more strange behavior from Dolphin and Nemo file managers, they’re working OK if I start from the /mnt location under File System. Adding to favourites is one of those strange behaviors that doesn’t work well.
Yeah maybe. It’s just strange that it works in most distributions out of the box other than Manjaro.
I really wanted to persevere as I seemed to feel more at home with Manjaro than a lot of other distributions I’ve tried in the past. And really wanted to get something working on the older laptop before I committed to putting it on the newer laptop. I figured I’d iron most of the bugs out and learn a bit before I got to that stage. And if I broke it, I could always reinstall it again!
Maybe it’s also an implementation difference thing? Thunar vs Dolphin, or something along those lines? How it’s done per file manager?
TLP ?
Have we tried disabling tlp to check if there is any difference?
1 Like
Not sure, but I’m using Nemo in Manjaro as dolphin doesn’t do it for me. But both are slow. I think I also tried Thunar too in Manjaro. But other distro’s use the same file managers (Dolphin, Nemo etc) and again, no real issues (even the 80MB/s better than 20MB/s)! Unless the distro’s are adding something extra to the file managers?
I checked to see if it was running with “systemctl status tlp” and this is the output
● tlp.service - TLP system startup/shutdown
Loaded: loaded (/usr/lib/systemd/system/tlp.service; enabled; vendor preset: disabled)
Active: active (exited) since Tue 2022-01-04 21:14:34 AEDT; 2 days left
Docs: https://linrunner.de/tlp
Process: 613 ExecStart=/usr/bin/tlp init start (code=exited, status=0/SUCCESS)
Main PID: 613 (code=exited, status=0/SUCCESS)
CPU: 470ms
Jan 04 21:14:33 ASUS-F550D systemd[1]: Starting TLP system startup/shutdown...
Jan 04 21:14:34 ASUS-F550D tlp[613]: Applying power save settings...done.
Jan 04 21:14:34 ASUS-F550D tlp[613]: Setting battery charge thresholds...done.
Jan 04 21:14:34 ASUS-F550D systemd[1]: Finished TLP system startup/shutdown.
From the looks of it, it’s active. I tried to disable it with TLP_ENABLE=0. However after a reboot and running “systemctl status tlp” it still says active? And the problems still there.
Do a
systemctl disable tlp.service --now
1 Like
Is this problem really related to Network? I don’t want to hijack this topic, but i have a general problem with much slower file transfers on my USB drives/HDDs compared to Windows, im also using Manjaro/KDE.
I think this point from schmidtp got ignored yet:
I can confirm this issue.
You use kernel 5.10?
I would be interested, how fast the smb connection is, if you use kernel 5.15 and mount the cifs share with option
vers=3.1.1
Thanks.
I just did this, and ran systemctl status tlp to confirm it was disabled. And rebooted just to be sure. Then mounted through Nemo again, still only 20MB/s (or thereabouts).
It could all be related. I just transferred a file between the two SSDs on the laptop. Both are the same type of SSD (Crucial MX500), just different capacities. The smaller one is formatted in NTFS (windows default), the other which I’m using is formatted in EXT4 (for this Manjaro install). It might also be worth mentioning, the NTFS drive is connected to the SATA port (where the normal HDD would be). The EXT4 drive is connected to where the old DVDRom drive was with a caddy.
If I transfer to the NTFS formatted drive, it transfers at about 45-55MB/s. But back the other way, it was so fast Nemo didn’t have time to put up the speed as it only took about 5 sec to transfer a 2.3GB file. So that would lead me to believe it’s something to do with the format type maybe.
Thanks. I had a similar thought too. I had downgraded several Kernels during this fault finding process as I thought it might have something to do with kernel additions. However, after mounting through FSTAB and the problem basically going away, I put the latest Kernel back on (5.15.7). Problem still exists when mounting through File Manager though.
So I’ve changed the FSTAB file to include Vers=3.1.1 for the QNAP only as I know this NAS can transfer flat out at 100MB/s (Gigabit) with it’s RAID. Although after a reboot, the drive mount is present in /mnt/QNAPmultimedia, but you can’t view any files. The NAS is about 4-5yo and I’m pretty sure when I ran some command early on, it said vers=2.0 (which is what I’ve been mounting it as). And that seems to work for this particular NAS.
NTFS is known to be slow, especially outside of proprietary systems.
I also had this slowndowns even on Ext4 to EXT4 HDDs. When i copy alot of files, it slows down every few secs and then the MB/s goes faster and slow down again… and again and again, i never experience this slow downs under Windows.
Yeah I’d seen something about this when I originally set my NAS up and deciding what file system to use. I didn’t expect to see any issues transferring from EXT4 to EXT4 via ethernet.
I had seen some posts with people using Mint that had the same issues when they upgraded the kernel a while back (maybe Ubuntu 16.04 to 18.04 I think), but seems to be fixed again. Maybe they were using a non LTS kernel version? That’s what lead me to trying older kernels. I even went back to about 4.4.294 which was the last one on the list in Manjaro.