- Hide menu

Blog

Apple’s iCloud Drive Slows Down a Device’s Download Speed by 10Mbps

Was tuning my home Wifi and noticed that some of my Apple devices (iPad, iPhone, MacBook Pro, iMac Pro) were not getting the same download speeds when testing via Speedtest. On a Mac with two user accounts, one account would consistently get about 10Mbps faster speed than another account. Initially thinking that there might be a user-level app that was running on log in, a launchdaemon or launchagent process, or a browser extension that was causing the slowdown in the affected account led to a process of turning everything off. But still, the slowdown didn’t go away.

As this was affecting not only Macs, but iPads and iPhones, I started looking deeper into what was similar with the accounts and devices that had the slow speed. It turned out to be Apple’s iCloud Drive feature. All the slow devices were logged into iCloud, and specifically, had the iCloud Drive feature turned on. When that is turned on, the download speed is slowed by about 10Mbps. It’s like it reserves this for it’s own use and is not available for other applications. And it’s not just in http web traffic, it’s at the device level as testing via Speedtest in a web browser or using the CLI test via Terminal yields the same reduction in speed.

You can do this simple test yourself. Just run Speedtest on any of the devices with iCloud Drive on, and then off. If you have a 100Mbps connection I suppose it doesn’t matter much, but losing 10Mbps isn’t what I signed up for in using iCloud Drive. Needless to say I’ve disabled iCloud Drive across all of them and reclaimed by DL speed, and will use one of the other cloud storage services like Dropbox or OneDrive that doesn’t silently take away my download speed.

Affected devices: Macs running 10.15.7 and 11.0.1; iOS and iPadOS 14.2

Migrating WordPress and setting up SSL on new host

I’ve just gone through moving a set of WordPress sites that was part of a multisite network on a Digital Ocean droplet. The motivation was having the multisite move off Ubuntu 14 to the more recent version Ubuntu 18.04.5 LTS so I could use certbot to install and keep up to date SSL certificates from LetsEncrypt.

There’s a lot of opinions, suggestions and tips on how to do this. One of the most informative is here. Essentially, there’s two approaches. Use the built in Export/Import fuction that exports an XML file that can be imported on another WordPress site, or a plugin that backs up everything and migrates it on another host at the filesystem level.

The benefit of the latter is that if you have a highly customised site with lots of plugins, after migrating to a new host, everything should just work. The downside is that there are many tools, none are free, and it’s not clear if it will work until you pay for the plugin.

Since my sites were relatively straightforward, I used the built in Export/Import function and then manually installed the required theme and settings. This might not work for complex e-commerce and customised sites.

To get SSL working, these tips on Digital Ocean is helpful: enable-https and apache-virtual-hosts. After setting it all up, you should check that you have all your virtual hosts setup properly.

Then check to see the quality of your SSL implementation at ssllabs.com. To get an A+ you might need to disable old protocols like TLS 1.0 and weak ciphers. And enabe HSTS. When that’s done, sit back and smile.

Accepting IPv6 ICMP on UDM and USG routers

There’s no clear instruction on how to allow this via the Unifi Controller. On my UDM running 1.5.6.2150 the solution is to Accept ICMPv6 protocol on the WAN-Local interface of the Firewall. This allows you to get 10/10 from the test site http://test-ipv6.com. If you’re using this test https://ipv6-test.com the results are different on Safari, Chrome and Firefox for me. Many comments say the ICMP test is broken and not to worry if you can’t get 20/20. Here is an external ping service to test whether you are reachable.

 

Use your Fujifilm camera as a webcam on macOS via USB

Just saw a video on using Fujifilm cameras as a web cam on Apple computers. Basically the steps are:

  1. Download and install Camera Live app on Github
  2. Download and install CamTwist Studio
  3. Run a command on your Mac via Terminal on the app you want to use the camera on
  4. Setup your Fujifilm camera
  5. Connect and go

Here are some tips on each of the steps:

  1. I’ve tested version 13 alpha on macOS 10.15.5
  2. I’ve tested version 3.4.3 on macOS 10.15.5
  3. The command to run in Terminal is
    “sudo codesign –remove-signature /Applications/<name of app>”
    I’ve tested this with Skype. Others are reporting that it works fine with Zoom.  For Skype, the command would be:
    “sudo codesign –remove-signature /Applications/Skype.app”
  4. Set camera to photo, not video, mode;
    In Connection Settings, select USB TETHER SHOOTING AUTO;
    Set camera to manual focus, and focus (You can try setting Pre-AF to On);
    Set exposure to manual and dial it in, check how it looks in Live View.
  5. Connect USB cable between camera and Mac;
    Start Camera Live app and select the Fuji camera (see image below);
    Start the CamTwist Studio app and select Syphon as the video source, and Camera Live in the Syphon server dropdown menu (see image below);
    Start the app you want to use the camera with eg Skype, and choose CamTwist as the camera (see image below).

How Preview settings in Lightroom Classic affect processing times

Lightroom Classic users know that there are five types of previews. The original four are Minimal, Embedded, Standard and 1:1. Then Smart Previews came along with the cloud based Lightroom. You also probably know that the time it takes to render 1:1 previews takes a lot longer than Standard and Smart versions. But you probably don’t know how much longer.

Here are some times for creating previews for 500 Nikon D850 Raw/NEF files using a 2017 iMac Pro with 3.2Ghz 8-core, 32GB RAM, 1TB SSD:

Import with Minimal Preview: 9 seconds
Rending Smart Previews 110 seconds
Render 1:1 Previews 471 seconds

So 1:1 Previews take almost 5 times longer than Smart Previews. About 1 second per file. One could argue that since Smart Previews allow you to edit with full functionality, there’s probably no benefit to use 1:1 previews anymore given the processing time penalty.

But what you may not know is the generally used Standard Preview has a setting that can also dramatically affect the processing time to generate previews. In the Catalog Settings, there is a Standard Preview Size. The default is an “auto” setting that Lightroom sets based on the resolution of the screen the software is running on. For an iMac Pro, that is a huge 5120 pixels for it’s 5K display. For a Retina MacBook Pro 13″, it is 3360 pixels.

Here are the times for generating standard previews for the 500 Nikon D850 files:

Standard Preview @ 5120px 219 seconds
Standard Preview @ 2880px 23 seconds
Standard Preview @ 2048px 19 seconds

The time required to render 5120 pixel previews is almost a whopping 10 times slower than ones at 2880 pixels, and Smart Previews take 5 times longer than the 2880 ones.

My takeaway is for my iMac Pro, set Standard Previews to 2048, and use Smart Previews instead of 1:1 Preview for the best compromise of speed versus detail.