Workgroup LAN via ethernet achieves less than 50% of expected Gigabit speed between two PCs & Samba

I am working to set up a local network between my two laptops for file sharing. Figured that a wired Gigabit ethernet connection should be fastest (1000 Gbit/s, i.e. s.th. like 110 MiB/s in practice), and this connection should be the bottleneck. Hard disks are SSDs (>500 MiB/s). Both laptops have Intel Gigabit cards; connection is done with a short CAT. 5E ethernet cable, no crossed cable needed since the cards are good enough.

Up front: When running both laptops on Windows (8.1 in my case) with the ethernet card drivers left in their default installation states, everything works well. I am getting 110 MiB/s when copying large iso files in any direction (from A to B and B to A, fetching and sending). In this case, all hard disk partitions involved are NTFS.

Going to the real case now: Running Linux on one machine, either Tumbleweed or Manjaro (dual bootable). Sticking to Windows 8.1 on the other machine. Same ethernet cable, hard disk partitions on the Linux side either ext4 or ntfs. Bottom line: The resulting file transfer speeds are not exactly acceptable, I am getting approx. 50 MiB/s only. Seldomly it’s 55, mostly just below 50, quite often only 40. This is the case with both Tumbleweed and Manjaro, and I am out of clues now after consulting many websites and even two textbooks.

What I did is as follows (short summary, this holds for both TW and Manjaro):

  1. On the Linux side, I configured a Link-Local ethernet connection using Network Manager. I can use whatever setting for the card speed is GUI available here (use auto-negotiation set to auto or manual, full duplex or half duplex) - same result.
  2. On the Linux side, avahi-daemon is running to do zeroconf. On the Windows side, zeroconf is handled by Bonjour with the two well-known Apple drivers extracted from iTunes and installed.
  3. At this stage, each laptop can ping the other one using either their 169.254.x.x zeroconf private IPV4 addresses, their IPV6 addresses, or their computer names.
  4. In order to share files residing on the Windows machine to the Linux machine, I set up the usual file sharings and access permissions in Windows Explorer. On the Linux machine, a Samba Client is being run. For both Tumbleweed and Manjaro, this works quite easily using just the file managers (Dolphin/Krusader in TW KDE Plasma, Thunar in Manjaro Xfce).
  5. In order to share files residing on the Linux machine to the Windows machine, I set up a Samba Server. This was the most complicated part for me, but I got it set up. Within this task, I went through an unproductive period until I realized that setting things up as root in /etc/samba/smb.conf and fiddling simultaneously with file sharing in the file managers as user is absolutely not advisable. So I have the Samba Server set up cleanly as root in /etc/samba/smb.conf only. Windows can connect to the Linux Samba shares using Windows Explorer.
  6. Firewalls are set up appropriately, too. In Tumbleweed, firewalld is preset nicely and comprehensively, and one just needs to assign a firewalld zone to the Link Local connection in Network Manager. In Manjaro, ufw with the gufw interface is used, and it takes opening the pre-configured samba ports.
  7. At this point in time, I think things are basically set up. I figure I will have to read more on how to make this local workgroup network as safe as possible beyond the defaults.

So now, I would need some help to find out why my file transfers within this littel LAN workgroup are so **** slow.

What can I provide to help you diagnose and hopefully solve this issue? All terminal commands were run while Link Local was connected.

$ sudo ethtool enp0s25
[sudo] Passwort für root: 
Settings for enp0s25:
        Supported ports:  TP ]
        Supported link modes:   10baseT/Half 10baseT/Full 
                                100baseT/Half 100baseT/Full 
                                1000baseT/Full 
        Supported pause frame use: No
        Supports auto-negotiation: Yes
        Supported FEC modes: Not reported
        Advertised link modes:  1000baseT/Full 
        Advertised pause frame use: No
        Advertised auto-negotiation: Yes
        Advertised FEC modes: Not reported
        Speed: 1000Mb/s
        Duplex: Full
        Port: Twisted Pair
        PHYAD: 1
        Transceiver: internal
        Auto-negotiation: on
        MDI-X: off (auto)
        Supports Wake-on: pumbg
        Wake-on: d
        Current message level: 0x00000007 (7)
                               drv probe link
        Link detected: yes
$ inxi -Fdxxxz
System:    Host: susytmblwdke8570 Kernel: 5.2.10-1-default x86_64 bits: 64 compiler: gcc v: 9.2.1 
           Desktop: KDE Plasma 5.16.4 tk: Qt 5.13.0 wm: kwin_x11 dm: SDDM Distro: openSUSE Tumbleweed 20190829 
Machine:   Type: Laptop System: Hewlett-Packard product: HP EliteBook 8570w v: A1028C1100 serial: <filter> Chassis: 
           type: 10 serial: <filter> 
           Mobo: Hewlett-Packard model: 176B v: KBC Version 50.1F serial: <filter> UEFI: Hewlett-Packard 
           v: 68IAV Ver. F.71 date: 04/19/2019 
Battery:   ID-1: BAT0 charge: 66.9 Wh condition: 66.9/66.9 Wh (100%) volts: 17.0/14.8 model: Hewlett-Packard Primary 
           type: Li-ion serial: <filter> status: Full 
           Device-1: hidpp_battery_0 model: Logitech M705 serial: <filter> charge: 60% rechargeable: yes 
           status: Discharging 
CPU:       Topology: Quad Core model: Intel Core i7-3720QM bits: 64 type: MT MCP arch: Ivy Bridge rev: 9 
           L2 cache: 6144 KiB 
           flags: lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx bogomips: 41502 
           Speed: 1198 MHz min/max: 1200/3600 MHz Core speeds (MHz): 1: 1198 2: 1197 3: 1197 4: 1197 5: 1198 6: 1204 
           7: 1198 8: 1197 
Graphics:  Device-1: NVIDIA GK107GLM [Quadro K1000M] vendor: Hewlett-Packard driver: nouveau v: kernel 
           bus ID: 01:00.0 chip ID: 10de:0ffc 
           Display: x11 server: X.Org 1.20.5 driver: nouveau unloaded: fbdev,modesetting,vesa alternate: nv,nvidia 
           compositor: kwin_x11 resolution: 1600x900~60Hz 
           OpenGL: renderer: NVE7 v: 4.3 Mesa 19.1.5 direct render: Yes 
Audio:     Device-1: Intel 7 Series/C216 Family High Definition Audio vendor: Hewlett-Packard driver: snd_hda_intel 
           v: kernel bus ID: 00:1b.0 chip ID: 8086:1e20 
           Device-2: NVIDIA GK107 HDMI Audio vendor: Hewlett-Packard driver: snd_hda_intel v: kernel bus ID: 01:00.1 
           chip ID: 10de:0e1b 
           Sound Server: ALSA v: k5.2.10-1-default 
Network:   Device-1: Intel 82579LM Gigabit Network vendor: Hewlett-Packard driver: e1000e v: 3.2.6-k port: 5040 
           bus ID: 00:19.0 chip ID: 8086:1502 
           IF: enp0s25 state: up speed: 1000 Mbps duplex: full mac: <filter> 
           Device-2: Intel Centrino Advanced-N 6205 [Taylor Peak] driver: iwlwifi v: kernel port: 4000 
           bus ID: 25:00.0 chip ID: 8086:0082 
           IF: wlo1 state: up mac: <filter> 
Drives:    Local Storage: total: 5.46 TiB used: 1.50 TiB (27.5%) 
           ID-1: /dev/sda vendor: Samsung model: SSD 860 EVO 2TB size: 1.82 TiB speed: 6.0 Gb/s serial: <filter> 
           rev: 2B6Q scheme: GPT 
           ID-2: /dev/sdb vendor: Samsung model: SSD 860 EVO 4TB size: 3.64 TiB speed: 6.0 Gb/s serial: <filter> 
           rev: 2B6Q scheme: GPT 
           Message: No Optical or Floppy data was found. 
Partition: ID-1: / size: 100.00 GiB used: 20.87 GiB (20.9%) fs: btrfs dev: /dev/sda4 
           ID-2: /home size: 48.97 GiB used: 2.02 GiB (4.1%) fs: ext4 dev: /dev/sda5 
           ID-3: /opt size: 100.00 GiB used: 20.87 GiB (20.9%) fs: btrfs dev: /dev/sda4 
           ID-4: /tmp size: 100.00 GiB used: 20.87 GiB (20.9%) fs: btrfs dev: /dev/sda4 
           ID-5: /var size: 100.00 GiB used: 20.87 GiB (20.9%) fs: btrfs dev: /dev/sda4 
           ID-6: swap-1 size: 18.00 GiB used: 0 KiB (0.0%) fs: swap dev: /dev/sda14 
Sensors:   System Temperatures: cpu: 50.0 C mobo: N/A gpu: nouveau temp: 127 C 
           Fan Speeds (RPM): N/A 
Info:      Processes: 256 Uptime: 1h 15m Memory: 15.59 GiB used: 1.51 GiB (9.7%) Init: systemd v: 242 runlevel: 5 
           target: graphical.target Compilers: gcc: N/A Shell: bash v: 5.0.7 running in: konsole inxi: 3.0.32
$ sudo hwinfo --netcard
12: PCI 2500.0: 0282 WLAN controller                            
  ... <omitted> ...
  Attached to: #17 (PCI bridge)

18: PCI 19.0: 0200 Ethernet controller
  [Created at pci.386]
  Unique ID: IDxx.xxxxxxx <edited out>
  SysFS ID: /devices/pci0000:00/0000:00:19.0
  SysFS BusID: 0000:00:19.0
  Hardware Class: network
  Model: "Intel 82579LM Gigabit Network Connection (Lewisville)"
  Vendor: pci 0x8086 "Intel Corporation"
  Device: pci 0x1502 "82579LM Gigabit Network Connection (Lewisville)"
  SubVendor: pci 0x103c "Hewlett-Packard Company"
  SubDevice: pci 0x176b 
  Revision: 0x04
  Driver: "e1000e"
  Driver Modules: "e1000e"
  Device File: enp0s25
  Memory Range: 0xd9400000-0xd941ffff (rw,non-prefetchable)
  Memory Range: 0xd943b000-0xd943bfff (rw,non-prefetchable)
  I/O Ports: 0x5040-0x505f (rw)
  IRQ: 34 (136310 events)
  HW Address: xx:xx:xx:xx:xx:xx <edited out>
  Permanent HW Address: xx:xx:xx:xx:xx:xx <edited out>
  Link detected: yes
  Module Alias: "pci:v00008086d00001502sv0000103Csd0000176Bbc02sc00i00"
  Driver Info #0:
    Driver Status: e1000e is active
    Driver Activation Cmd: "modprobe e1000e"
  Config Status: cfg=no, avail=yes, need=no, active=unknown
$ testparm
Load smb config files from /etc/samba/smb.conf
Loaded services file OK.
Server role: ROLE_STANDALONE

Press enter to see a dump of your service definitions

# Global parameters
[global]
        logon drive = P:
        logon home = \\%L\%U\.9xprofile
        logon path = \\%L\profiles\.msprofile
        map to guest = Bad User
        name resolve order = bcast host lmhosts wins
        netbios name = TMBLWD-8570
        preferred master = Yes
        server string = ""
        usershare allow guests = Yes
        usershare max shares = 100
        workgroup = LRLINWINGRP
        idmap config * : backend = tdb
        include = /etc/samba/dhcp.conf

[TW-AVs-I-shared]
        comment = I in AVs shared
        force user = myself
        path = /home/myself/AVs/I
        read only = No
        valid users = myself

[TW-VMs-V-shared]
        comment = VMs in VMs shared
        force user = myself
        path = /home/myself/VMs/VMs
        read only = No
        valid users = myself

[TW-XCs-X-shared]
        comment = X in XCs shared
        force user = myself
        path = /home/myself/XCs/X
        read only = No
        valid users = myself

Remarks: For setting up the Samba Servers on both Linuxes, the sticky post by swerdna here https://forums.opensuse.org/showthread.php/520609-Configure-Samba-for-a-Workgroup-in-the-local-LAN was most helpful - thanks for providing this.
I did also consult this very recent thread here https://forums.opensuse.org/showthread.php/537300-Network-Ethernet-WIRED-router-not-at-1000Mbps-in-Leap-but-is-in-Windows(dual-boot), but despite the promising title I couldn’t get much help for my problem from it.

I have a couple of questions or doubts regarding my procedure right away: Is it correct to have zeroconf (as avahi/Bonjour) running at the same time as Samba (netBIOS)? Is the “name resolve order = bcast host lmhosts wins” in /etc/samba/smb.conf the best possible way; it was taken from swerdna’s post cited above.

Any help is gratefully apreciated in advance.

Doing a more systematic investigation into the file transfer speeds achieved, the picture becomes quite weird, at least for me.

I have the ethernet cards in both laptops set to auto-negotiate now. Checking with ethtool on the TW side, I see 1000Mb/s and full duplex (same output as reported above) - guess that should be fine.

**When any file transfer (copy using Windows Explorer) is initiated from the Windows machine, it runs at 110 MiB/s as expected. **This does not depend on the transfer direction and not on how source/target partitions are formatted (ext4 or ntfs). This is as one would expect it to work.

However, the slow transfer speeds are seen only when any file transfer is initiated from the Linux machine, using Dolphin/Krusader on TW and Thunar on Manjaro. No matter what I try, I get only 30-50 MiB/s, occasionally only 25, occasionally up to 55. This does not depend on the transfer direction. Maybe there is some dependency on what the file system is on the source/target partitions, ext4 or ntfs. This is UNexpected and not really acceptable.

Almost needless to say: When copying large files from one place on the SSD of the Linux machine to another place on that SSD (all internal within the Linux machine), I see the expected SSD speed around 500 MiB/s.

Any ideas?

Next step: Just did an ethernet performance test with iperf3. The Windows machine can send 112 MiB/s to the Linux TW machine. The Linux TW machine achieves send rates of up to 100 or 105 (very rarely) MiB/s, sometimes down to 80 or so. So what does that mean now, and why do I get only 40-50 MiB/s file transfer speed on the TW machine (cf. all the above)?

Edit: Remember that both machines achieve 110 MiB/s file transfer speeds when run under Windows.

Hi
What tools on the windows machines are you using… bit like in windows when copying files to a USB device, it says it’s finished but still see activity on the USB device…

On the linux machine run something like atop and/or netatop to see what the real receive/transmit data is.

Hi, thanks for coming in.

I just looked at “simple” measurements when copying files from one machine to the other.
On Windows: (1) the Windows Explorer “Copy” progress bar with details unfolded, i.e. that graph over time. (2) Task Manager > Performance with ethernet download/upload graphs.
On Linux: Just all the file managers’ progress information while copying, i.e. on Tumbleweed the Copying widget from Dolphin, on Manjaro the Copying window from Thunar.

The iperf3 performance measures are accurate, I guess.

Installed atop in Tumbleweed; YaST doesn’t find any netatop. If I am reading the atop output correctly, then there is a line labeled enp0s25 (the ethernet NIC), which has “sp 1000Mbps” all the time and “so 440 Mbps” when I copy a large file from Tumbleweed to the Windows machine. I interpret this as the same 440 Mbit/s from T to W, when the Windows Task Manager at the same time shows an incoming rate of the same 440 Mbit/s. So this is the 55 MiB/s file transfer speed I was seeing at best.

Hope my reading of atop is correct, and hope it might help you believe what I see.

EDIT: Remark: Actually, I am not so sure anymore regarding M (=1,000,000) as decimal or Mi (with 1024’s) in all the various displays. But anyway, I am looking at losing a factor of 2, not some few times of 2.4%).

Tried to copy the upper part of the atop output:

ATOP - susytmblwdke8570                                           2019/09/02  17:08:40                                           --------------                                            10s elapsed
PRC |  sys    6.94s |  user   7.44s |               |  #proc    266 |  #trun      2 |  #tslpi   635 |                | #tslpu     0  | #zombie    0  | clones    28  |               | no  procacct  |
CPU |  sys      69% |  user     75% |  irq       7% |  idle    649% |  wait      0% |  steal     0% |  guest     0%  |               | ipc notavail  | cycl unknown  | curf 2.23GHz  | curscal  61%  |
cpu |  sys       8% |  user      7% |  irq       6% |  idle     78% |  cpu005 w  0% |  steal     0% |  guest     0%  |               | ipc notavail  | cycl unknown  | curf 1.85GHz  | curscal  51%  |
cpu |  sys      11% |  user     12% |  irq       0% |  idle     77% |  cpu001 w  0% |  steal     0% |  guest     0%  |               | ipc notavail  | cycl unknown  | curf 1.83GHz  | curscal  50%  |
cpu |  sys       9% |  user     10% |  irq       0% |  idle     81% |  cpu003 w  0% |  steal     0% |  guest     0%  |               | ipc notavail  | cycl unknown  | curf 2.40GHz  | curscal  66%  |
cpu |  sys       9% |  user     10% |  irq       1% |  idle     80% |  cpu000 w  0% |  steal     0% |  guest     0%  |               | ipc notavail  | cycl unknown  | curf 2.48GHz  | curscal  68%  |
cpu |  sys       9% |  user      9% |  irq       0% |  idle     82% |  cpu002 w  0% |  steal     0% |  guest     0%  |               | ipc notavail  | cycl unknown  | curf 2.39GHz  | curscal  66%  |
cpu |  sys       8% |  user      8% |  irq       0% |  idle     83% |  cpu006 w  0% |  steal     0% |  guest     0%  |               | ipc notavail  | cycl unknown  | curf 2.77GHz  | curscal  76%  |
cpu |  sys       8% |  user      9% |  irq       0% |  idle     83% |  cpu004 w  0% |  steal     0% |  guest     0%  |               | ipc notavail  | cycl unknown  | curf 1.83GHz  | curscal  50%  |
cpu |  sys       7% |  user      9% |  irq       0% |  idle     84% |  cpu007 w  0% |  steal     0% |  guest     0%  |               | ipc notavail  | cycl unknown  | curf 2.30GHz  | curscal  63%  |
CPL |  avg1    0.98 |  avg5    0.40 |               |  avg15   0.27 |               |               |  csw   411751  | intr   62325  |               |               | numcpu     8  |               |
MEM |  tot    15.6G |  free    4.2G |  cache   9.4G |  dirty   5.3M |  buff  188.9M |  slab  381.1M |  slrec 219.0M  | shmem 109.7M  | shrss  16.4M  | vmbal   0.0M  | hptot   0.0M  | hpuse   0.0M  |
SWP |  tot    18.0G |  free   18.0G |               |               |               |               |                |               |               |               | vmcom   4.3G  | vmlim  25.8G  |
DSK |           sda |  busy     51% |  read    1022 |               |  write      4 |  KiB/r    511 |  KiB/w     23  | MBr/s   51.0  | MBw/s    0.0  |               | avq     0.00  | avio 4.96 ms  |
NET |  transport    |  tcpi   49402 |  tcpo  375829 |  udpi       1 |  udpo       1 |  tcpao      7 |  tcppo      3  | tcprs      0  | tcpie      0  | tcpor      3  | udpnp      0  | udpie      0  |
NET |  network      |  ipi    49403 |  ipo    16416 |               |  ipfrw      0 |  deliv  49403 |                |               |               |               | icmpi      0  | icmpo      0  |
NET |  enp0s25  45% |  pcki   49326 |  pcko  375736 |  sp 1000 Mbps |  si 3311 Kbps |  so  450 Mbps |  coll       0  | mlti       0  | erri       0  | erro       0  | drpi       0  | drpo       0  |
NET |  wlo1      0% |  pcki       5 |  pcko       7 |  sp  135 Mbps |  si    0 Kbps |  so    0 Kbps |  coll       0  | mlti       0  | erri       0  | erro       0  | drpi       0  | drpo       0  |
NET |  lo      ---- |  pcki      72 |  pcko      72 |  sp    0 Mbps |  si    6 Kbps |  so    6 Kbps |  coll       0  | mlti       0  | erri       0  | erro       0  | drpi       0  | drpo       0  |

Hi
Try the command atop -n to also show what apps are using bandwidth.

The netatop and netatop kmp (you need to modprobe netatop and start the netatopd service) are in my repo here;

Project: https://build.opensuse.org/package/show/home:malcolmlewis:openSUSE_General/netatop
Download: https://download.opensuse.org/repositories/home:/malcolmlewis:/openSUSE_General/openSUSE_Tumbleweed/x86_64/

Hi
Just did some quick tests here, copying an iso image via scp and via Nautilus between two machines with 1Gb interfaces, both ways I see it peaking at around 720Mbps.

Both machines are connected to a 1Gb switch both are using cat6 cable. If I switch to a cat5 cable I see the performance drop to 100Mbps as the remote machine switches down as expected.

So what is your setup between systems? Routers, switches, cables etc?

Although what I wrote is more than 10 years ago now,
It’s all still completely relevant to what you are trying to do.

https://sites.google.com/site/4techsecrets/optimize-and-fix-your-network-connection

A determining factor of course is whether you’ve set up a direct link unshared with any machines and whether you have any intervening devices in your network.

If you have anything that might cause interference on the line (other machines, EMF emitting devices like elevators and other large motors, microwave ovens, etc), then modifying the TCP/IP Congestion Control algorithm can help. Distance , particular site to site or over WAN links can also be a factor a different algorithm can address.

Otherwise…
My article suggests numerous things you can implement to improve network performance…

  • Configure Layer 2 Jumbo Frames
  • Increase your TCP/IP sliding window sizes
  • Shift system resources to your networking, increasing buffers, more.

I’d also note that you are introducing complications by transferring between MSWindows and Linux machines…you will have to know how both OS handles networking at a very low level to fully optimize, you should transfer only between same OS if you want to uncomplicate your variables.

Additionally,
If you’re experiencing some extremely large performance deficit, although t’s possible for a lot of little problems to add up, you should first look at a fundamental mis-configuration or connection… Like not enabling full duplex, a mis-configured intervening device like a switch, bridge or router, a bad connection or bad wire, not offloading to your NIC, etc.

TSU

Maybe the problem is because NTFS is slow compared to other file systems.

Thanks guys up to now. Lots of homework for me, but only tomorrow.

What I can answer right away: Nothing between the two laptops, just a CAT.5E cable. NIC Settings on the Linux side cf. above ethtool output and hwinfo. Nothing else hooked up to either laptop, in particular no router. No internet access during all of this.

Will be back tomorrow, German time.

Some additional suggestions…

First,
You should clarify and define your objectives.
So, for example there is a big difference between trying to break speed records and transfer a file in the fastest way possible compared to prepping for a real world LAN use with numerous clients running different applications and even browsing the Internet. For the latter, you could justify first trying to do the former to establish a benchmark, but it’s unreasonable to think that simply doing the former will set up the latter use.

Now, some specifics…

  • Try a CAT6 cable
  • Configure full duplex manually on both machines, don’t enable auto-negotiate
  • Since you say you get double the speed with a straight file transfer (you didn’t say what protocol and application) but your problems are with a SMB file transfer, then that suggests your problems are likely related to your use of the SMB protocol. The SMB protocol does a lot more than simply support a file transfer, numerous features are built into it related to security, discovery, integrity and more things I’m not thinking of. Some descriptions of the protocol follows…

Note the section on performance issues
https://en.wikipedia.org/wiki/Server_Message_Block

As the protocol used by MSWindows Network Shares, of course its documentation is excellent
https://docs.microsoft.com/en-us/windows/win32/fileio/microsoft-smb-protocol-and-cifs-protocol-overview

And, although you can’t really compare your scenario to anyone else’ exactly because there are so many critical factors involved, an Internet search might suggest degraded performance you’re seeing is not that much different than what others have complained about…

So,
In the end you may need to state your parameters and objectives…
If your LAN hosts will eventually all be gigabit capable, then maybe the settings suggested in my paper can be implemented to improve throughput, but only to a point if you choose to use SMB. If you absolutely need the extra speed (Users often won’t notice the difference between 50Mbit vs 110 Mbit unless the files are gigabytes in size), then you might try something else like architecting iSCSI storage and maybe data replication across all the workstations in your network so that needed files have a good chance of being “local” and won’t need to be transferred across the network on demand.

HTH,
TSU

Thanks, malcolmlewis, tsu and nrickert - guess I have the very experts right here to help!

Let me turn to the various homework items, not in good order, and may omitting quotes the original posts at some points.


First, continuing on atop and netatop:

Installed netatop and netatop-kmp-default from your repo, modprobe’d netatop and started the netatopd service - great, it worked.

This is the output from “sudo atop”, then command “n”, taken while the Tumbleweed machine was sending a file to a share on the Windows machine:

ATOP - susytmblwdke8570                 2019/09/03  11:31:36                 --------------                  10s elapsed
PRC |  sys    5.34s |  user   5.21s  |  #proc    262 |  #tslpi   298  | #tslpu     0  |  #zombie    0  | #exit      0  |
CPU |  sys      52% |  user     50%  |  irq       6% |  idle    693%  | wait      0%  |  ipc     0.48  | curscal  40%  |
cpu |  sys      18% |  user     21%  |  irq       0% |  idle     61%  | cpu003 w  0%  |  ipc     0.54  | curscal  51%  |
cpu |  sys       7% |  user      8%  |  irq       0% |  idle     85%  | cpu001 w  0%  |  ipc     0.56  | curscal  36%  |
cpu |  sys       8% |  user      5%  |  irq       0% |  idle     87%  | cpu000 w  0%  |  ipc     0.38  | curscal  36%  |
cpu |  sys       2% |  user      2%  |  irq       6% |  idle     90%  | cpu005 w  0%  |  ipc     0.45  | curscal  41%  |
cpu |  sys       6% |  user      5%  |  irq       0% |  idle     89%  | cpu006 w  0%  |  ipc     0.35  | curscal  46%  |
cpu |  sys       4% |  user      4%  |  irq       0% |  idle     92%  | cpu004 w  0%  |  ipc     0.50  | curscal  35%  |
cpu |  sys       3% |  user      3%  |  irq       0% |  idle     94%  | cpu002 w  0%  |  ipc     0.41  | curscal  34%  |
cpu |  sys       3% |  user      2%  |  irq       0% |  idle     96%  | cpu007 w  0%  |  ipc     0.28  | curscal  37%  |
CPL |  avg1    0.72 |  avg5    0.32  |  avg15   0.23 |  csw   213263  | intr   52378  |                | numcpu     8  |
MEM |  tot    15.6G |  free    9.9G  |  cache   4.7G |  buff   77.3M  | slab  358.3M  |  vmbal   0.0M  | hptot   0.0M  |
SWP |  tot    18.0G |  free   18.0G  |               |                |               |  vmcom   1.9G  | vmlim  25.8G  |
DSK |           sda |  busy     48%  |  read     965 |  write      4  | MBr/s   48.2  |  MBw/s    0.0  | avio 4.94 ms  |
NET |  transport    |  tcpi   47106  |  tcpo  355282 |  udpi       4  | udpo       4  |  tcpao      0  | tcppo      0  |
NET |  network      |  ipi    47113  |  ipo    15453 |  ipfrw      0  | deliv  47112  |  icmpi      2  | icmpo      2  |
NET |  enp0s25  42% |  pcki   47106  |  pcko  355265 |  sp 1000 Mbps  | si 3156 Kbps  |  so  425 Mbps  | erro       0  |
NET |  wlo1      0% |  pcki       7  |  pcko       7 |  sp  300 Mbps  | si    0 Kbps  |  so    0 Kbps  | erro       0  |

  PID   TID  TCPRCV  TCPRASZ TCPSND  TCPSASZ  UDPRCV UDPRASZ  UDPSND  UDPSASZ    BANDWI     BANDWO   NET CMD         1/2
10218     -   47089       83  15440    33712       0       0       0        0 3155 Kbps   416 Mbps  100% smb.so
 1252     -       0        0      0        0       4     153       4       78    0 Kbps     0 Kbps    0% nscd
 2385     -       0        0      0        0       0       0       0        0    0 Kbps     0 Kbps    0% kwin_x11
 2392     -       0        0      0        0       0       0       0        0    0 Kbps     0 Kbps    0% plasmashell
 1921     -       0        0      0        0       0       0       0        0    0 Kbps     0 Kbps    0% X
10068     -       0        0      0        0       0       0       0        0    0 Kbps     0 Kbps    0% atop
10150     -       0        0      0        0       0       0       0        0    0 Kbps     0 Kbps    0% dolphin
 9460     -       0        0      0        0       0       0       0        0    0 Kbps     0 Kbps    0% konsole
 1542     -       0        0      0        0       0       0       0        0    0 Kbps     0 Kbps    0% NetworkManager
 2012     -       0        0      0        0       0       0       0        0    0 Kbps     0 Kbps    0% upowerd
 1229     -       0        0      0        0       0       0       0        0    0 Kbps     0 Kbps    0% dbus-daemon
  486     -       0        0      0        0       0       0       0        0    0 Kbps     0 Kbps    0% haveged
   11     -       0        0      0        0       0       0       0        0    0 Kbps     0 Kbps    0% rcu_sched
 2287     -       0        0      0        0       0       0       0        0    0 Kbps     0 Kbps    0% dbus-daemon
  157     -       0        0      0        0       0       0       0        0    0 Kbps     0 Kbps    0% kworker/4:1-mm
 1032     -       0        0      0        0       0       0       0        0    0 Kbps     0 Kbps    0% irq/36-iwlwifi
 9962     -       0        0      0        0       0       0       0        0    0 Kbps     0 Kbps    0% kworker/u16:1-
 2346     -       0        0      0        0       0       0       0        0    0 Kbps     0 Kbps    0% kded5
 2422     -       0        0      0        0       0       0       0        0    0 Kbps     0 Kbps    0% org_kde_powerd
 1404     -       0        0      0        0       0       0       0        0    0 Kbps     0 Kbps    0% polkitd
    1     -       0        0      0        0       0       0       0        0    0 Kbps     0 Kbps    0% systemd
 1838     -       0        0      0        0       0       0       0        0    0 Kbps     0 Kbps    0% wpa_supplicant
 2413     -       0        0      0        0       0       0       0        0    0 Kbps     0 Kbps    0% rtkit-daemon
  158     -       0        0      0        0       0       0       0        0    0 Kbps     0 Kbps    0% kworker/6:1-ev
  195     -       0        0      0        0       0       0       0        0    0 Kbps     0 Kbps    0% kworker/u16:7-
  442     -       0        0      0        0       0       0       0        0    0 Kbps     0 Kbps    0% btrfs-cleaner

I interpret this as seeing the outgoing ethernet speed to be around 50 MiByte/s again, and all ethernet bandwidth being consumed by the smb.so process. Nobody else eats bandwidth. Am I correct?


Next, let me try to summarize what I would exclude as possible reasons for the apparent loss of more than a factor of 2 in ethernet bandwidth.

Hardware, physical conditions around my place: I think the ethernet cards on both laptops are capable of Gigabit, as well as the interconnect cable CAT.5E (1.5 meters). No obvious electromagnetic or radio frequency interferences.
Why that? When both machines are run under Windows (8.1-64 bit), all transfers do run happily at 110-115 MiByte/s (>980 Mbit/s) in any direction.

And, as already mentioned, there is nothing between the two laptops but this one ethernet cable.


Third, filesystem types involved:

On the Linux machine, I use both ext4 and ntfs partitions to read from as well as send to. Of course, on the Windows machine there are only ntfs partitions involved.
I am getting the same slow speeds of 50 MiByte/s when initiating any transfer from the Linux machine, i.e. using Dolphin (TW KDE) or Thunar (Manjaro Xfce) to push a file to a share on the Windows machine or pull a file from Windows. This slow speed is seen in the same way when using either of the ext4 or ntfs partitions on Linux.


Fourth, how is the ethernet card set up under Linux and Windows:

Cable: cf. above in this post, no issue. Ethernet card setup: On both machines, auto negotiation is enabled, and “ethtool enp0s25” shows 1000Mbps and full duplex, cf. the first post in this thread. At one point in time, I did an incomplete test - disabled auto-neg on the Linux machine and set it to Manual 1000Mbps/full duplex - still only 50 MiByte/s. I will have to do this setting the NICs to Manual properly, on both machines. But I am afraid this would not be successful either.


Use a different copy method on the Linux machine:
Until now, I had Dolphin/Krusader and Thunar only.

malcolmlewis, I tried scp, but I couldn’t get the syntax right, or I am missing something else (SSH?)
Let’s say, I want to scp a file abc.iso from TW to Windows. Open a terminal in the source directory. The Windows machine has computer name win81-pm-8560 on Windows, can be talked to as win81-pm-8560.local using zeroconf (avahi/Bonjour) and can be seen as win81-pm-8560 from Samba. What is the appropriate scp command line then?
scp abc.iso winusername@win81-pm-8560/winsharename/windirectoryname/
Couldn’t figure it out, too stupid.


What should we conclude from my iperf3 ethernet performance measurements?
Cf. one of the posts above:

Does this 800 Mb/s correspond a little bit to your 720Mbps, malcolmlewis? If that were true, would this point to the KDE (Dolphin/Krusader) ways of implementing file transfers from the file managers, and to the Xfce (Thunar) way of implementing its file sharing plugin?
malcolmlewis, what desktop environment are you using? Tumbleweed with GNOME?


Anyway, I’ll finish for now. Please, give me your comments, suggestions, and please correct as much as possible where I am going wrong.

I am really wondering with respect to two observations:

  • I have the same loss of a factor of 2 for both Tumbleweed and Manjaro (i.e., Arch-based). However, both do use Network Manager, and I did all setups (Link Local connection, Samba) in roughly the same way, except for different stancas in the global section of /etc/samba/smb.conf (Manjaro by default had a lot more than Tumbleweed).
  • And I am facing more than a factor of 2 loss in ethernet speed, but only when initiating any transfer from the Linux machine to the Windows one - not from Windows to Linux. This factor of >2 is such a big loss that I have a little bit of a hard time to believe that there is a bunch of small losses mounting up. I do more easily tend to believe that there is basically one setting somewhere that’s causing things to go downhill.

It might be very rewarding to discuss your question of “what are your objectives?” with you, tony su. Maybe later, if you agree. This post is getting bigger and bigger … please bear with me.

Hi malcolmlewis, please, I need a bit more help wrt kernel modules. This netatop and netatop-kmp-default was the first one I did “on my own”.

What I did after installing from your repo via YaST was:

$sudo modprobe netatop
$sudo systemctl start netatopd

Then

lsmod | sort

shows netatop to be loaded, and

$sudo atop

followed by command “n” or

$sudo atop -n

yield the desired output in terminal.

Now, three questions please:

  • After a reboot, lsmod shows netatop to be loaded again. From literature I know I could remove it with “rmmod netatop”. But where is the config file that calls for netatop to be loaded at boot? Can’t find a config file mentioned in various textbooks (TW here, with KDE Plasma).
  • I did not enable netatopd to be started at boot. Nevertheless, after booting “sudo atop -n” gives the “usual” (?) output. Do I have to enable netatopd? Normally, I don’t want to flood my system with logs.
  • How about your repository? Does the netatop-kmp-default get updated every time Tumbleweed gets a new kernel? Immediately, or does it require manual action on your side? (Reason to ask: I was really trapped in a big mess a few months ago when I installed TW from a published image that had a messed-up virtualbox-kmp-default not fitting the kernel.)

Thanks!

Hi
Likely from atop, is this running in the background?

The kmp will update automatically on the openSUSE Build Service, after the first kernel update the kmp will/should drop into the kernel module location ‘weak-updates’ if it’s not updated and should keep going until it rebuilds and is available to install. Once you have finished your testing, you can always uninstall…

If you manually installed, then you would need to keep an eye on the repository after a kernel update.

For scp/sftp/ssh you would need to be running a ssh daemon on the windows machine else on a windows machine you can use putty or winscp.

I just use scp <filename> username@host:<filename> will place the file on a linux system in the username home directory.

My desktop is GNOME…

For a 1.5m distance, yes I doubt that there would likely be much of a diff between CAT5e and CAT6.

Unless it’s part of your objectives, I wouldn’t test using an encrypted protocol like ssh, scp or sftp… I’d just transfer using ftp (my choice) or tftp… If the test transfer files were tiny, <3MB then I would even consider HTTP (but text based protocols like HTTP do worse as the file size increases).

I also would not be averse to running a packet sniffer or packet capture, then look at the dump looking for any problems in the transmission like failures and re-sends.

IMO the following from your atop may provide a clue… Depending on what kind of activity your’e testing, that’s a lot of traffic going in both directions and might speak to a fundamental inefficiency in the SMB protocol or non-optimized tuning (You’ll have to inspect the packets to know what is in the traffic) The heavy traffic in both directions can almost by itself be responsible for halving throughput in one direction

  PID   TID  TCPRCV  TCPRASZ TCPSND  TCPSASZ  UDPRCV UDPRASZ  UDPSND  UDPSASZ    BANDWI     BANDWO   NET CMD         1/2
10218     -   47089       83  15440    33712       0       0       0        0 3155 Kbps   416 Mbps  100% smb.so

Since your MSWindows test machine is Win8.1, I’d guess you should try to enforce SMB3 in your SAMBA.
Implement the configuration and mount your share as described in “Tests and Code” in the following
https://wiki.samba.org/index.php/SMB3-Linux
And here is a little more info on configuring SMB3 in this “AskUbuntu” thread
https://askubuntu.com/questions/1009455/smb-2-or-3-with-samba-version-4-3-11

Else if you don’t mount as SMB3, since MS introduced SMB3 in MSWindows 8.1, you should probably run your MSWindows<>MSWindows tests when at least one machine is Win7 or earlier for comparison to a default SAMBA setup.

IMO,
TSU

Hi,

Not sure what heavy traffic means. What I’m doing all the time is copy large iso files (2, 4 or 8 GiB) from here to there. But as you say, without knowing what’s inside the packets one doesn’t know whether that’s the reason.

I now set “client min protocol = SMB2” and “client max protocol = SMB3” in my /etc/samba/smb.conf. Unfortunately, no change at all. The full Samba doc says that min/max protocol should not be set as the automatic negotiation phase in the SMB protocol takes care of choosing the appropriate one.

Sorry, I don’t quite grasp what you mean in your last paragraph. Do you mean I should mount the Windows shares in my Linux /etc/fstab? Until now I have them in Dolphin/Krusader and also Thunar show up in the file managers’ side panels under network and/or under places. Will try mounting via fstab tomorrow, when I can figure out the most appropriate mount statement. Plus, I would need to understand the mechanics in the cases (1) Windows machine not present at boot of Linux and (2) either one of the Linux or Windows machines coming up later.

Cheers.

Hi
If you have access to a Cat6 cable, I would try that to see if there is an improvement. As for WinX tools, I would suggest a third party tool to verify the observations from the winX default tools.

Hi Tony, if I am reading the atop -n outputs right (your red markings, with average packet sizes and the 10 sec interval), then there is a Send rate of 52 MiB/s and a Receive rate of 390kiB/s. The Send rate is just what I see all the time, cannot judge on the Receive rate.

Hi Malcolm, no easy access to a Cat6 cable, but I‘ll try, although Win<>Win runs at 980 MBits/s with 5E.

Cheers!

The red numbers are numbers of packets (I assume).
That’s an extraordinary amount of traffic going in the opposite direction no matter which way the file is being transferred, and because Ethernet is fundamentally a serial connection (only one packet can exist on the wire at any given moment and machines communicate that way) it has to affect how fast the file can be transferred.

The next step should be to determine if that traffic is normal SMB overhead or if it’s due to dropped packets which is fairly unlikely on a very short, direct, unshared link. Until you actually inspect those packets, everything is speculation but to me this is a promising path of exploration.

Also, I’d try forcing SMB3 by setting that as the minimum also before backing off to allowing SMB2, at least for testing. You’re trying to configure an apples to apples comparison with your 2 MSWindows transfer test.

Regarding getting a CAT6 cable, I doubt that should make much difference on such a short distance.
And besides, if the test between two MSWindows machines was over the existing cable, then at least in that test it made no diff.

TSU