2

we operate an 80TB QNAP NAS, both for storing bulk data as well as TimeMachine backups of our laptops. The NAS itself can sustain over 300 MByte/sec of write speeds when accessed from multiple ethernet-connected machines, and TimeMachine has decent performance (configured as AFP share).

However when accessed over wifi, the performance drop is massive - it doesn't show any "live" speeds but leaving a laptop for 20 hours (no energy saving) and only 850MB of transferred data speaks enough. Granted, our network setup is a bit non-standard as our Cisco WLAN AP controller is at our central datacenter connected to our office via a 100/100 leased line and has to share traffic with other clients, but even under loaded conditions an SSH transfer to the NAS achieves ~5 MByte/sec.

What exactly does TimeMachine do when using a network share? Is it possible that there are MTU fuck-ups somewhere along the connection, or does AFP require ultra low latency links (when over wifi, ping is 40ms)?

  • WiFi will almost always be slower than any wired connection as WiFi is shared bandwidth and also subject to interference and signal attenuation. You might best be served by doing the first backup via wired network and then WiFi will only have to update changed files. – Steve Chambers Sep 18 '18 at 15:37
  • @SteveChambers that's what I'm doing, the problem is that changesets easily reach hundreds of megabytes in an hour for me. – Marco Schuster Sep 24 '18 at 13:22
2

After your comments and my questions answered, here are my recommendations/best practices.

Probably the only real remedy would be to have the office AP switch local traffic indeed locally. This feature is available in Cisco's APs/AP controller, called FlexConnect.

If you read the first paragraph and look at the illustration in the following PDF, you'll see that this is pretty much your use case. The AP controller is located in a remote location connected via a dedicated (VPN'ed) line – but traffic within the local branch/office is switched locally.

You should probably have a word with your net ops people to see if this is possible to setup or if your AP fits the requirements (a list of supported APs is also in the PDF).

https://www.cisco.com/c/en/us/td/docs/wireless/controller/8-1/Enterprise-Mobility-8-1-Design-Guide/Enterprise_Mobility_8-1_Deployment_Guide/ch7_HREA.pdf

The PDF is from the AP controller software version 8.1, but this feature goes way back (formerly known as Hybrid REAP). You should probably also consult the documentation version corresponding to your AP controller software version to have an accurate list of supported APs.


The real limiting factor will always be the sluggish data rate caused by your specific network setup, regardless of AFP vs. SMB. So, all the following measures are only additional remedies and best practices you can try.

MTU

Check/set your maximum non-fragmenting network MTU over the Wi-Fi connection.

http://www.mseri.me/fixing-wifi-on-os-x-by-tweaking-the-mtu/

There is still the magic MTU number of 1453 floating around the interwebs in regards to (at least older) macOS versions, especially when interacting with Cisco equipment.

http://osxdaily.com/2013/01/14/set-mtu-size-from-the-command-line-of-mac-os-x/

SMB vs. AFP

SMB should generally be preferred over AFP by now, as AFP has been deprecated by Apple for quite some time.

AFP is not even supported anymore when sharing from APFS-formatted volumes.

https://support.apple.com/en-us/HT208018

macOS SMB

Time Machine backups over SMB are supported in QNAP QTS version 4.3 and later.

https://www.qnap.com/en-us/how-to/tutorial/article/using-time-machine-to-back-up-your-mac-to-a-qnap-nas-via-smb/

By default, macOS packet-signs SMB connections, which greatly impacts transfer performance (transfer speed here with signing disabled is doubled!).

As I have no idea if/where you can disable signing globally/server-side in QTS (Syno guy :) or if this would be recommended in your use case, you can disable SMB packet-signing client-side on specific macOS machines.

https://support.apple.com/en-us/HT205926

You can check if signing is disabled by using the command "smbutil statshares -a" (a SMB volume has to be mounted, otherwise the command output will be blank).

Please see the following URL fore more info:

https://kb.promise.com/thread/disable-smb-signing-on-os-x-10-11-5-10-12-x/

Samba settings

The two following best practices are not really related to Time Machine but greatly improve the general SMB experience for macOS clients.

You should augment the Samba config file (smb.conf) on the QNAP NAS according to the following URL:

https://support.apple.com/en-us/HT207128

Ignore the FCP X specific stuff, this setting basically enables macOS-specific features in Samba.

Please check the QNAP specifics for Samba configuration. (For instance, Synology uses a private Samba build with some configuration differences, like commas instead of spaces for multi-attribute config lines.

Also, augment the Samba config file by this:

access based share enum=yes

This setting forces Samba SMB shares to resemble the behaviour of AFP shares by only showing shares that you have permissions for. By default Samba shows all shares, even the ones you don't have permissions for, which shows a permissions error message when trying to access a share w/o permissions.

Disable .DS_Store on network shares

You can try to disable creation of .DS_Store files on network volumes. This can speed up SMB performance. First paragraph in the following URL:

https://support.apple.com/en-us/HT208209

Time Machine

Try to exclude as many items/locations in the Time Machine preferences as feasible. For instance, I excluded the /Applications folder, as it is usually the same/less hassle to reinstall an application than to recover it from a backup. Also, the ~/Downloads folder is usually a good no-backup candidate. Additionally – but this is depending on the specific workflow – it can be feasible to exclude directories that contain data managed by version control systems.

Time Machine is a low priority process. Any other activity will suspend the Time Machine backup process. You can try to disable the low priority throttling in macOS to speed up Time Machine. Please see the following URL for more info (including how to make this setting permanent):

http://www.mackungfu.org/massively-speed-up-time-capsule-time-machine-backups

You can then use the free tool "Time Machine Editor" to exclude your work hours from the Time Machine schedule.

https://tclementdev.com/timemachineeditor/


DISCLAIMER: Use these recommendations at your own risk. Specifially, try out the settings/modifications first on a test machine before rolling out to production systems.

These are my 2 cents (actually, it's more like 1,50 Euro).

Assuming from your name that you are located in a German-speaking region:

Viel Erfolg!

[EDIT] With QTS 4.3.5 it looks like QNAP added GUI options to enable access based share enumeration, so it is probably not necessary anymore to manually edit the smb.conf for this functionality. From the QNAP QTS 4.3.5 release notes:

SAMBA - Added Microsoft Networking Advanced Options for ABE (access-based enumeration) and ABSE (access-based share enumeration).

0

Can you test the raw WiFi performance from the notebook machine to the NAS with iperf? I'm pretty sure there is a QNAP package for this (I'm a Syno user myself).

Also, Time Machine is a low-priority process. Maybe give this a try:

https://www.defaults-write.com/speed-up-time-machine-backups/

  • Here the results from an iperf run. There should me more than enough headroom. [ ID] Interval Transfer Bitrate [ 6] 0.00-10.00 sec 89.3 MBytes 74.9 Mbits/sec sender [ 6] 0.00-10.06 sec 89.3 MBytes 74.5 Mbits/sec receiver UDP same picture: [ 6] 0.00-10.00 sec 119 MBytes 100 Mbits/sec 0.000 ms 0/91369 (0%) sender [ 6] 0.00-10.05 sec 118 MBytes 98.5 Mbits/sec 0.136 ms 893/91368 (0.98%) receiver – Marco Schuster Sep 24 '18 at 13:26
  • Well, compared to here, your network is indeed reely slow. (600+ Mbit/s = 75 MB/s here on AC WiFi, even at some distance to the AP.) Can you please elaborate a bit on your setup and use case? Guessing from your reported data rate, is the WiFi traffic in your location routed over the mentioned 100 Mbit line? What are the aforementioned changesets in the hundreds of megabytes size range? Did you try the transfer speed to an "normal" (Finder-mounted) AFP share? – Gummibando Sep 26 '18 at 11:56
  • Yes, exactly, the wifi is routed over the 100/100 line, and then back to the NAS. It's a weird setup but apparently required because our network ops team doesn't want to maintain expensive Cisco controllers at each of our location and they don't yet have a solution to route location-local traffic at the location. Speeds via "ordinary" AFP are atrocious (1MByte/sec tops), while transfers over SMB and SSH approach 8-10MByte/sec via WiFi. Over Gbit cable speeds for AFP, SMB and SSH clock in at 60 MByte/sec. Apparently there is something that makes AFP over high-latency Wifi super slow. – Marco Schuster Sep 27 '18 at 13:54
  • After testing with Xcode's Network link conditioner pref pane (200msec latency up/down), it indeed seems that AFP suffers heavily from high latency. – Gummibando Sep 27 '18 at 21:24
  • support.apple.com/en-us/HT205926 – Gummibando Sep 27 '18 at 21:42

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .