2 different AFP connection methods result in different transfer speeds (GigE LAN)

  • I have a rock64 single board computer with openmediavault 4.
    I use hdd (Ext4) connected to USB3 port on a GigE LAN.
    OS: Mojave 10.14.4


    My AFP transfer speed depends on the connection methods that OSX provides:


    • Finder(Sidepanel): Locations
    • Finder > Go > Connect to Server… (CMD + K)
      afp://192.168.0.64



      Results:

      LANconnectionAFP
      connection
      Filesize (MB)Transfer
      speed (MB/s)
      WLANFinder24850
      WLANFinder1.04020
      WLANFinder4.89010
      WLANCMD + K9.39036,6
      GigEFinder4.89010
      GigECMD + K131.07064,5



      It is strange that via the Finder method, transfer speed drops significantly with time.
      Another thing that puzzels me:My brother has the same NAS hardware setup and OSX.Regardless of the connection method he has > 80 MB/s constantly.
      FYI:My Computer ---- my brother's computerMojave 10.14.4 ---- Mojave 10.14.2MacBook Pro (15-inch, 2018) ---- Mac mini (Late 2014)2,6 GHz Intel Core i7 ---- 2,6 GHz Intel Core i516 GB 2400 MHz DDR4 ---- 8 GB 1600 MHz DDR3

  • Ethernet

    Code
    ping rock64
    ping: cannot resolve rock64: Unknown host


  • WiFi

    Code
    ping rock64
    ping: cannot resolve rock64: Unknown host
  • So you're dealing with wireless and wired networking connections at the same time (en0 and en8). At least cmd-k and Finder sidebar use the same destination address so maybe it's related to you still using wireless connections while having connected Ethernet?


    See https://support.apple.com/HT202480 starting at 'How to change the network service order' -- your wired connection needs to be on top otherwise Wi-Fi gets preferred over Ethernet. And if a connection is already established over Wi-Fi when you add an Ethernet adapter this connection will still remain wireless.


    And to get reliable data you would need to test with something like Helios LanTest.

  • So you're dealing with wireless and wired networking connections at the same time (en0 and en8). At least cmd-k and Finder sidebar use the same destination address so maybe it's related to you still using wireless connections while having connected Ethernet?


    See https://support.apple.com/HT202480 starting at 'How to change the network service order' -- your wired connection needs to be on top otherwise Wi-Fi gets preferred over Ethernet. And if a connection is already established over Wi-Fi when you add an Ethernet adapter this connection will still remain wireless.


    And to get reliable data you would need to test with something like Helios LanTest.

    sorry, I didn't make that clear. No, I never have WiFi on while being connected via ethernet. I did the tests one at a time.
    Usually I always chose my network adapter manually.


    I've heard about Helios. I'll give it a try asap.

  • The different transfer speeds depending on the connection method seem to be related to Docker Desktop App. (Docker Desktop Version 2.0.0.3 (31259))

    It was set to "start Docker desktop when you log in" and I didn't notice that.


    (Testfile: 9.110 MB)


    Docker NOT running:

    AFP via Finder:Sidepanel

    73,4 MB/s


    AFP via Menu "Connect to server" (CMD + K)
    70 MB/s


    --------------


    Docker running:


    AFP via Finder:Sidepanel
    38 MB/s

  • I ran iostat 10 on my Mac while copying a 9.110 MB file:

  • I ran iostat 10 on my Mac

    Sorry, it was about running iostat 10 on the OMV box. And two times this procedure (to generate insights):


    • 20 seconds idle
    • container started for 30 seconds
    • container stopped (another 20 seconds)

    Then again with a copy in parallel. It's about getting insights what the Docker container does (high IO and/or CPU activity potentially bottlenecking the NAS throughput)

  • (No file copying)

    • Docker NOT running (20s)
    • Docker started
    • Docker running (30s)
    • Docker stopped (20s)
  • (copying files)

    • Docker NOT running (20s)
    • Docker started
    • Docker running (30s)
    • Docker stopped (20s)

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!