Mac SMB file transfer varies significantly based on mounting direction

Currently reading
Mac SMB file transfer varies significantly based on mounting direction

3
3
Operating system
  1. Linux
  2. macOS
Hello,

I found this forum while searching and it appears nicely done. I have filed a support request with Synology but that can take a while, perhaps someone here has an idea.

I'm testing a scenario to be implemented on our live show productions and have come across an oddity that I can't explain. I'm attempting to transfer files from a NAS to a Mac and the transfer speed varies almost by a factor of two depending on whether I mount the NAS on the Mac via SMB, or mount the Mac on the NAS via CIFS Remote Mount in DSM.

I set up a test scenario with an isolated network. Here are the details -

DS918+, DSM v6.2.3-25426 Update 2, SMB=on, AFP=off
- all transfers from a DSM shared non-encrypted folder to a Target Mac.
No other DSM activity going on, no remote access.
Target Mac - MacOS 10.14.6, transfers via SMB, SMB packet signing=off, SMB local caching=off
Admin Mac - MacOS 10.14.6, SMB packet signing=off, SMB local caching=off
All 1G connections for this test, the production version will be a faster NAS with 10G connections.

Test 1 -
Admin Mac is logged into DSM via Chrome and looking at File Manager but not doing anything.
Target Mac has file sharing off, the NAS folder is mounted on the Target Mac via SMB.
Using Finder, transfer several folders of media files from the NAS to the Target Mac.
Transfer speed varies between 100-110MB/s, not bad for a Mac.
NAS CPU = ~12%

Test 2 -
Admin Mac is logged into DSM via Chrome and looking at File Manager.
Target Mac has file sharing on with only SMB enabled.
Via the Admin Mac - mount the Target Mac on the NAS in DSM as a CIFS Remote Mount.
Via the Admin Mac in DSM transfer the same folders of media files from the NAS to the Target Mac.
Transfer speed varies between 48-65MB/s, not good and odd given Test 1 results. This difference persists between reboots, remounts, etc.
NAS CPU = ~44%

Any idea why this is happening? The Resource Monitor doesn't indicate anything odd except the significant CPU usage when using CIFS Remote Mount.

Thanks,
Hugh
 
So initiator in test1 is the Mac and in test2 is the NAS but the direction of data flow is the same, NAS to Mac.

Guessing this is done all locally using lan ip addresses?

Also for test 2 have you tried to copy data from nas to a mac destination but using ssh session and not the browser? Are speeds the same?
 
Also for test 2 have you tried to copy data from nas to a mac destination but using ssh session and not the browser? Are speeds the same?
This also occurred to me: is the web client (DSM portal/File Station) adding overhead? Does it go through the DSM associated data held in the @eaDir folders even when copying out to remote folder?

Logging in to the NAS with SSH and doing a command line cp may throw up different results.
 
This also occurred to me: is the web client (DSM portal/File Station) adding overhead? Does it go through the DSM associated data held in the @eaDir folders even when copying out to remote folder?
I can attest that there are some "problems" when it comes to speeds while transferring using the web ui, but then again, if I am not remote, I use AFP protocol to transfer all my data. Never have any problems with that method.
 
Hello Rusty and fredbert,
Thanks for the responses.

I will try ssh and see if that makes a difference. It won’t work for production as they need a gui but may narrow the issue a bit.

I also wondered about the Admin mac’s involvement in the copy process so for one of the repeat tests, after initiating the copy, I disconnected the Admin Mac. The transfer completed indicating the Admin Mac wasn’t necessary, and it didn’t speed it up.

Interesting thought about afp, I didn’t test that because the vibe from Apple (my opinion) seems to be that smb is the future, I will see how afp does.

It may be a few days before I’m back in that studio but thanks again.
Sincerely,
Hugh
 
Hello again,
Synology support got back to me with their conclusion and closed the case. Best stated in their words -
"I have heard back from our developers and after reviewing our documentation and your current mounting method this slower transfer performance appears to be due to the fact the Mount Remote Folder options is only capable of using SMBv2 at this time. This limitation is on DSM at it's current version. SMBv3 is slated to be used in the upcoming release of DSM 7.0, but at this time we are unable to set this mounting protocol for Mount Remote folder to SMB3. As you know from all of the testing thusfar we have done on this case, there does not appear to be any significant method we can use to increase the transfer rate, and will be continued to be bogged by this limitation."

My interpretation is there are three pieces to the information from the developers in this response -
- CIFS Remote Mount uses SMBv2.
- CIFS Remote Mount will be slow until changes are made in DSM.
- SMBv2 is what causes a near-quadrupling of CPU usage and significantly slower transfer speeds.

The first point - CIFS Remote Mount uses SMBv2 - is true, understood.
The second point - CIFS Remote Mount will be slow until changes are made in DSM - is informative and I can look for other options besides Synology for our proposed workflow.
The third point - SMBv2 is what causes a near-quadrupling of CPU usage and significantly slower transfer speeds - is not empirically accurate as SMBv2 running on other server platforms does not have the same result. It's a DSM-specific problem.

Two items for me -
- CIFS Remote Mount in DSM via SMBv2 is not implemented well.
- It took more than two weeks to get past the initial screening phase to actually have my case escalated to a developer. My initial test conditions and reproduction steps were so clear, concise, and eliminated so many variables that if the support had gone the way it goes with our other broadcast suppliers I would have been in contact with a developer on the first day.
As I mentioned several times during the discussions, I understand Synology has it's time consuming support script to follow and I was always polite and concise. Many of the requests would have been allayed if someone had simply read my initial test scenarios and responded appropriately to what I had written instead of blindly following a script. A large waste of my and their time, Synology needs a procedure to read test scenarios such as mine and immediately understand I saved more than two weeks of our time and escalate immediately.
Frustrating, ridiculous waste of my time, and it's obvious Synology does not want to be in the broadcast world. We move fast, need quick support, and will pay for it.

Thank you for the assistance on this forum, I appreciate it.
Sincerely,
Hugh
 

Create an account or login to comment

You must be a member in order to leave a comment

Create account

Create an account on our community. It's easy!

Log in

Already have an account? Log in here.

Similar threads

It’s rare but not impossible for a switch to start behaving weirdly under certain conditions. Not all...
Replies
68
Views
21,095
Thankyou it saves me, for some reason some peeps decided to go with weird naming and I am the one stuck...
Replies
9
Views
2,272
Well, I created a share within DSM and it seems to be working, "preparing to copy". My bad, I had shared...
Replies
1
Views
1,033
I agree that curiousity is a good thing, but I'd prefer doing this test with a spare NAS, which I don't...
Replies
7
Views
3,861
  • Question
yes,i can, i only try it on windows, i find the solution,i clone/make a new sharing folder with same file...
Replies
2
Views
1,327
  • Solved
Well, I sorted the problem out. I ensured that the Windows firewall rules were meant specifically for the...
Replies
16
Views
3,202

Welcome to SynoForum.com!

SynoForum.com is an unofficial Synology forum for NAS owners and enthusiasts.

Registration is free, easy and fast!

Back
Top