Page 3 of 4 FirstFirst 1234 LastLast
Results 21 to 30 of 34

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

  1. #21
    Join Date
    Jun 2008
    Location
    Podunk
    Posts
    26,822
    Blog Entries
    15

    Default Re: Workgroup LAN via ethernet achieves less than 50% of expected Gigabit speed between two PCs

    Quote Originally Posted by 111MilesToGo View Post
    Hi Malcolm, no easy access to a Cat6 cable, but I‘ll try, although Win<>Win runs at 980 MBits/s with 5E.
    Hi
    Still be interesting to verify, also if you open the WinX device manager details for the ethernet and check the settings in the 'Advanced' tab and compare to the ethtool output.

    FWIW I tested WinX (have the same network cards as you) using winscp to transfer an iso image to the linux machine, best I saw was 270Mbps which was as reported on the WinX machine.
    Cheers Malcolm °¿° SUSE Knowledge Partner (Linux Counter #276890)
    SUSE SLE, openSUSE Leap/Tumbleweed (x86_64) | GNOME DE
    If you find this post helpful and are logged into the web interface,
    please show your appreciation and click on the star below... Thanks!

  2. #22

    Default Re: Workgroup LAN via ethernet achieves less than 50% of expected Gigabit speed between two PCs

    Hi guys, back again.

    First a little remark on my approach to building a computer system (and other things, too): Since one is putting piece upon piece and layer upon layer, I like to make sure every single one of them works (most reasonably) well at each step. I feel any issues will be exceedingly difficult to hunt down when one starts looking at all sorts of performance only after building the whole system. That's why I build this tiny network of two computers via LAN and test it thoroughly; of course, my target as of now is more complicated.

    So, I owed you and myself to do two more tests, unfortunately both without positive results - the file transfer speeds from the Linux to the Windows machine remain crippled:
    • I purchased a CAT6 ethernet cable - good to have it for the sake of itself.
    • I nailed the Samba client protocols on the Linux side to the SMB3_02 Windows 8.1 protocol,i.e. in /etc/samba/smb.conf I first put in

    Code:
    client min protocol = SMB3_02
    client max protocol = SMB3_02
    then I also added
    Code:
    client ipc min protocol = SMB3_02
    client ipc max protocol = SMB3_02
    No success. According to "man smb.conf" Samba does in fact auto negotiate the protocols to use; looks like.

    Next thing to state again is that all measurements do fully agree:
    • On the Linux machine, atop -n, Conky, the KSysGuard task manager, and the file managers' widget displays while copying files
    • On the Windows machine, the Task Manager > Performance displays, and the Windows Explorer display while copying files

    Then, I undertook testing the ethernet connection (same Link Local in Network Manager as always) with iperf3 a bit more comprehensively. The following results are reproducable:
    • When the Windows machine acts as sender, the network just runs at 980 Mbps (close to Gigabit) as expected.
    • When the Linux machine acts as sender, the network runs at approx. 600 Mbps for the first 5 seconds, then jumps to s.th. like 800 Mbps until the 45 seconds mark is reached, then jumps to 900-950 (typically 930) Mbps; it stays there for the remainder of the testing time (5 minutes here).

    Lastly, I undertook checking the file transfer speeds once again:
    • When the file transfer is initiated from the Windows machine, i.e. pull a file from a share on the Linux machine to a local Windows directory, or push a file from Windows to a share on the Linux machine, everything runs at 980 Mbps - as expected for a Gigabit connection.
    • However, as was seen all the days now, when initiating a file transfer from the Linux machine (both directions, pull and push), it only runs at anything in the range of <250 to >400 Mbps only, i.e. a disappointing 30 to 50 MiBytes/s. (These transfers take a couple of minutes each, i.e. far beyond the 45 seconds mark referred to above in the iperf3 report.)

    All these observations do hold when running the Linux machine on Tumbleweed (KDE Plasma) as well as on Manjaro (Xfce).

    So, in summary, the status now is as follows, and my tentative conclusions are:
    • Any hardware faults (cards, cable) and device driver settings (both on Windows and Linux) can be excluded, as well as outside interferences (EMI, RFI). This is proven by (1) the iperf3 performance tests with the machines run under Linux and Windows, resp., and (2) by the fact that I am getting full Gigabit speeds when I run both machines under Windows.
    • My primary suspect for losing this factor of >2 in ethernet bandwidth is Samba. I guess I should not say "losing", but instead "not using", since atop -n didn't reveal any other ethernet enp0s25 usage then. The fact that the observed loss of a factor of >2 in bandwidth does occur for both Tumbleweed and Manjaro is in line with suspecting Samba, since Samba and quite similar /etc/samba/smb.conf's are a common element of both operating systems. (Of course, the ethernet card and driver as well as Link Local settings are the same for both OSs, too.)
    • More particularly, I tend to think it is the Samba client part that's causing this loss. Indication: The loss occurs only when the Linux machine accesses a share on the Windows machine, i.e. when Linux acts as a Samba client - if I am not victim to a fundamental misconception. When Windows accesses a share on the Linux machine, i.e. when Linux acts as a Samba server, everything is running at full speed. That was why I had some hope when putting those "client min/max protocol" stanzas into the /etc/samba/smb.conf, but that didn't help, probably since auto negotiation works.
    • My secondary suspect are the two desktops (Plasma, Xfce) and/or their file managers / file transfer and Samba plugins (Dolphin/Krusader, Thunar). However, I'd rank them second only as potential culprits, because on the surface they are different; but of course I don't know at all whether the two OSs go back to the same resources wrt file transfers at some point.

    So, dear mates and helping hands and brains, what do you think of my conclusions? Potentially pointing in the right direction? How can we go on in search of the culprit?

    I gave the Arch Linux Wiki on Samba and Networks (usually a real good source) a good read, but couldn't find too much help there - maybe you could double-check or find other sources of information. The Arch Wiki on Samba has a paragraph "Improve throughput" in the "Server" chapter, but (1) according to my hypothesis that would be the wrong chapter, and (2) it says "be careful" all the time, since tweaks might cripple TCP or cause data loss due to race conditions etc. BTW, this is similar to your 10-yr old paper on tuning networks, dear Tony, which also cries "be careful" all over the place.

    What can we do now? Any ideas are very welcome. In particular, please correct me if my conclusions and suspects above are wrong in any way.


    PS: Dear Malcolm, since you are Administrator here at the Forum, would you please add the tag "Samba" to this thread if you deem it to be useful? I had started with s.th. like ethernet, speed, LAN as far as I remember. Thanks!

  3. #23
    Join Date
    Jun 2008
    Location
    Podunk
    Posts
    26,822
    Blog Entries
    15

    Default Re: Workgroup LAN via ethernet achieves less than 50% of expected Gigabit speed between two PCs

    Quote Originally Posted by 111MilesToGo View Post
    <snip>

    PS: Dear Malcolm, since you are Administrator here at the Forum, would you please add the tag "Samba" to this thread if you deem it to be useful? I had started with s.th. like ethernet, speed, LAN as far as I remember. Thanks!
    Hi
    Looks like a good summary and one would have to conclude it's somehow Samba protocol related. It will be interesting to see if there is a change with a cat6 cable.

    Re you PS, the tag Samba is already added to the thread, or did you mean the thread title?
    Cheers Malcolm °¿° SUSE Knowledge Partner (Linux Counter #276890)
    SUSE SLE, openSUSE Leap/Tumbleweed (x86_64) | GNOME DE
    If you find this post helpful and are logged into the web interface,
    please show your appreciation and click on the star below... Thanks!

  4. #24
    Join Date
    Jun 2008
    Location
    Podunk
    Posts
    26,822
    Blog Entries
    15

    Default Re: Workgroup LAN via ethernet achieves less than 50% of expected Gigabit speed between two PCs

    Hi
    Have a look at these tweaks in the [global] section...

    https://eggplant.pro/blog/faster-sam...e-performance/
    Cheers Malcolm °¿° SUSE Knowledge Partner (Linux Counter #276890)
    SUSE SLE, openSUSE Leap/Tumbleweed (x86_64) | GNOME DE
    If you find this post helpful and are logged into the web interface,
    please show your appreciation and click on the star below... Thanks!

  5. #25

    Default Re: Workgroup LAN via ethernet achieves less than 50% of expected Gigabit speed between two PCs

    Quote Originally Posted by malcolmlewis View Post
    ... Re you PS, the tag Samba is already added to the thread, or did you mean the thread title?
    Thanks, I actually meant both. Sorry, I discovered the "Edit tags" box only after writing that PS; so I guess the tags are fine now.

    Please, would you mind adding "Samba" to the thread title, e.g. like this if it fits:
    Code:
    Workgroup LAN via ethernet achieves less than 50% of expected Gigabit speed between two PCs for Samba
    Thanks.

  6. #26

    Default Re: Workgroup LAN via ethernet achieves less than 50% of expected Gigabit speed between two PCs

    Quote Originally Posted by malcolmlewis View Post
    ... It will be interesting to see if there is a change with a cat6 cable.
    Did get a CAT6 cable (cf. the first bullet point in my big post today), but to no avail re the speed issue here. Nice to have, though...

  7. #27

    Default Re: Workgroup LAN via ethernet achieves less than 50% of expected Gigabit speed between two PCs

    Quote Originally Posted by malcolmlewis View Post
    ... Have a look at these tweaks in the [global] section...

    https://eggplant.pro/blog/faster-sam...e-performance/
    Quote Originally Posted by tsu2 View Post
    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/4techs...ork-connection
    Yes, thanks to you both, I do also think these are the directions to try now. I did find quite some internet posts (e.g. Arch, Ubuntu) regarding tweaks in the /etc/smaba/smb.conf global section. And I also found indications that mounting the shares offered from the Windows machine with CIFS on the Linux machine would improve performance considerably. I will need to look at such stuff, including maybe look at Linux textbooks, hopefully be able to sort the tips by effect size, and - yes! - be careful when tweaking things. Well, quite some web posts are from the days of 100Mbps ethernets, and from the days of magnetic spinning hard disks...

  8. #28
    Join Date
    Jun 2008
    Location
    Podunk
    Posts
    26,822
    Blog Entries
    15

    Default Re: Workgroup LAN via ethernet achieves less than 50% of expected Gigabit speed between two PCs

    Quote Originally Posted by 111MilesToGo View Post
    Yes, thanks to you both, I do also think these are the directions to try now. I did find quite some internet posts (e.g. Arch, Ubuntu) regarding tweaks in the /etc/smaba/smb.conf global section. And I also found indications that mounting the shares offered from the Windows machine with CIFS on the Linux machine would improve performance considerably. I will need to look at such stuff, including maybe look at Linux textbooks, hopefully be able to sort the tips by effect size, and - yes! - be careful when tweaking things. Well, quite some web posts are from the days of 100Mbps ethernets, and from the days of magnetic spinning hard disks...
    Hi
    If there are I/O issues, the atop output will tell you
    Cheers Malcolm °¿° SUSE Knowledge Partner (Linux Counter #276890)
    SUSE SLE, openSUSE Leap/Tumbleweed (x86_64) | GNOME DE
    If you find this post helpful and are logged into the web interface,
    please show your appreciation and click on the star below... Thanks!

  9. #29

    Default Re: Workgroup LAN via ethernet achieves less than 50% of expected Gigabit speed between two PCs

    Quote Originally Posted by malcolmlewis View Post
    Hi
    Have a look at these tweaks in the [global] section...

    https://eggplant.pro/blog/faster-sam...e-performance/
    Hi, now we are down to the question of Samba Server or Samba Client being the culprit, or both or none. In my long post today, I have promoted an hypothesis that it is the Samba Client; for the reasons, cf. above
    Quote Originally Posted by 111MilesToGo View Post
    ... ... ...
    From the smb.conf manual:
    Code:
           socket options (G)
    
                   Warning
                   Modern server operating systems are tuned for high network performance in the majority of situations;
                   when you set socket options you are overriding those settings. Linux in particular has an auto-tuning
                   mechanism for buffer sizes that will be disabled if you specify a socket buffer size. This can
                   potentially cripple your TCP/IP stack.
    
                   Getting the socket options correct can make a big difference to your performance, but getting them
                   wrong can degrade it by just as much. As with any other low level setting, if you must make changes to
                   it, make small changes and test the effect before making any large changes.
    
               This option allows you to set socket options to be used when talking with the client.
    
               Socket options are controls on the networking layer of the operating systems which allow the connection to
               be tuned.
    
               This option will typically be used to tune your Samba server for optimal performance for your local
               network. There is no way that Samba can know what the optimal parameters are for your net, so you must
               experiment and choose them yourself. We strongly suggest you read the appropriate documentation for your
               operating system first (perhaps man setsockopt will help).
    
               You may find that on some systems Samba will say "Unknown socket option" when you supply an option. This
               means you either incorrectly typed it or you need to add an include file to includes.h for your OS. If the
               latter is the case please send the patch to samba-technical@lists.samba.org.
    
               Any of the supported socket options may be combined in any way you like, as long as your OS allows it.
    
               This is the list of socket options currently settable using this option:
    
                      •   SO_KEEPALIVE
    
                      •   SO_REUSEADDR
    
                      •   SO_BROADCAST
    
                      •   TCP_NODELAY
    
                      •   TCP_KEEPCNT *
    
                      •   TCP_KEEPIDLE *
    
                      •   TCP_KEEPINTVL *
    
                      •   IPTOS_LOWDELAY
    
                      •   IPTOS_THROUGHPUT
    
                      •   SO_REUSEPORT
    
                      •   SO_SNDBUF *
    
                      •   SO_RCVBUF *
    
                      •   SO_SNDLOWAT *
    
                      •   SO_RCVLOWAT *
    
                      •   SO_SNDTIMEO *
    
                      •   SO_RCVTIMEO *
    
                      •   TCP_FASTACK *
    
                      •   TCP_QUICKACK
    
                      •   TCP_NODELAYACK
    
                      •   TCP_KEEPALIVE_THRESHOLD *
    
                      •   TCP_KEEPALIVE_ABORT_THRESHOLD *
    
                      •   TCP_DEFER_ACCEPT *
    
               Those marked with a '*' take an integer argument. The others can optionally take a 1 or 0 argument to
               enable or disable the option, by default they will be enabled if you don't specify 1 or 0.
    
               To specify an argument use the syntax SOME_OPTION = VALUE for example SO_SNDBUF = 8192. Note that you must
               not have any spaces before or after the = sign.
    
               If you are on a local network then a sensible option might be:
    
               socket options = IPTOS_LOWDELAY
    
               If you have a local network then you could try:
    
               socket options = IPTOS_LOWDELAY TCP_NODELAY
    
               If you are on a wide area network then perhaps try setting IPTOS_THROUGHPUT.
    
               Note that several of the options may cause your Samba server to fail completely. Use these options with
               caution!
    
               Default: socket options = TCP_NODELAY
    
               Example: socket options = IPTOS_LOWDELAY
    Am I reading this correctly, socket options being potentially good for a Samba Server only? So, if my hypothesis is correct, then I wouldn't go for socket options. What do you think?

    Anyways, I dared to put
    Code:
    socket options = IPTOS_LOWDELAY TCD_NODELAY
    into the global section of smb.conf, as this was specifically worded "for local network" in the man page. But no change to the transfer speed from Linux to Windows.

    Hmmm... I'll keep on...

    Reiterating: It would help me most if you could dismiss or confirm my a.m. hypothesis regarding the Samba Server / Client concept. Server = make shares available to other computers on the network and serve any request from others, Client = access shares on other computers on the network and ask them to serve something? Yep, I know, the most stupid question possible...

  10. #30

    Default Re: Workgroup LAN via ethernet achieves less than 50% of expected Gigabit speed between two PCs & Sa

    Hi guys, finally, I got a major breakthrough! Still have to test it thoroughly, but I am in good spirits now. Hope that holds.

    Previously, I had been accessing the shares offered by the Windows machine with the help of Dolphin's network stuff, i.e. by entering
    Code:
    smb://winusername@wincomputername/winsharename
    in the address bar, or by creating a link in Dolphin's side panel with that URL.
    I still don't know what is underneath. Is it the kdenetwork-filesharing package, and then what below that?
    I think for Xfce / Thunar it is the gvfs-smb package.
    Sorry, in my previous posts on this thread I had been hinting at that, but I had not stated it as clearly as I do now, since I wasn't aware of potential differences.

    Anyway, I found a tip on the web that mounting the shares offered by other network computers on the Linux machine with CIFS gives much higher speeds. So now:
    Code:
    sudo mount -t cifs
        //wincomputername/winsharename /run/media/linusername/linmountpoint
        -o username=winusername,password=winuserpassword,workgroup=MYWORKGROUP,iocharset=utf8,uid=linusername,gid=lingroup
    And boom ... network transfers initiated from the Linux machine now run at 980 Mbps, too! As measured by atop -n on the Linux side and the Task Manager on the Windows side.

    Still have to get more experience with this. As far as I saw up to now on the Windows incoming side, some transfers of large (couple of GB) files are running at 980 Mbps all the time until dropping down to 0, others run at 980 for some time and then drop to half the speed for some more time before going to 0. The Dolphin copy widget runs very differently, at 500 MiB/s first (i.e. the read speed of the Linux SSD), then decreasing gradually - must be due to reading the file into the Linux RAM and sending it out as fast as the Windows machine accepts it.

    Guess that's it!

    From here on, I still have to go a bit of a conceptual way: How do I do that CIFS mounting properly, taking into account that the Windows shares won't be present at all times. With two scripts for mounting and unmounting? In fstab (with nofail or noauto)? How to avoid long time-out waits at Linux shutdown when the shares are not present?

Page 3 of 4 FirstFirst 1234 LastLast

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •