Significant performance improvement with external SSD via USB 2.0

[sinejoe]

Claude and Gemini were very helpful in tweaking a few SMB settings on the TC and my mac which have resulted in substantially improved performance, mainly meaning much more stable, longer-running backup sessions to an external SSD connected to my Time Capsule via USB 2.0. See Gemini's summary below...

Model: TimeCapsule8,119, 5th generation AirPort Time Capsule (2013, 2TB/3TB model)

[Idea/Performance Tuning] Optimizing Samba 4 & Time Machine for Legacy Time Capsule Hardware

I’ve been using this terrific project to setup a custom Samba 4 stack on my legacy Apple AirPort Time Capsule (Gen 5, NetBSD 6).

While the base setup is amazing, I ran into severe bottlenecking, high CPU usage, and transient connection drops—especially when running initial/large backups to an External SSD plugged in via USB 2.0 on legacy hardware with extremely limited RAM (256MB/512MB).

With some tuning, I managed to get the system running much more stably with ~6.5% CPU utilization for active transfers and under 10MB RAM footprint per active connection, completely saturating the USB 2.0 bus without dropping out.

I wanted to share the exact configuration changes we made so they can help other users, or perhaps be integrated into one or more of the default configuration templates.

---

1. The Core Bottlenecks Addressed

1. Thread pooling & Context-switching overhead: Modern Samba uses asynchronous I/O thread pools (AIO) by default. On a low-power single/dual-core CPU, context-switching between these threads consumes more CPU cycles than it saves.
2. Memory Exhaustion (OOM): Every active SMB connection spawns a new smbd child process. Lingering connections or massive thread pools can easily trigger NetBSD's Out-Of-Memory (OOM) killer.
3. Cryptographic Signing Load: SMB packet signing adds heavy cryptographic load to the server's CPU. While macOS's Time Machine engine (backupd) mandates this for security on the backup itself, disabling it for other operations (Finder, directory scans) significantly lowers system load.
4. USB Connection Dropping: USB 2.0 links to external SSDs can occasionally experience transient disconnects under high I/O, causing the volume to unmount and leaving Time Machine hanging.

---

2. Server-Side Optimizations (smb.conf)

We modified the template inside src/timecapsulesmb/assets/boot/samba4/common.d/50-runtime-staging.sh to restrict resource consumption, optimize latency, and eliminate threading overhead:

[global]
    # 1. Threading & Thread-Pool Elimination
    # Turning off Asynchronous I/O prevents Samba from spawning background worker threads,
    # reducing memory usage and CPU context-switching on low-core-count ARM chips.
    aio read size = 0
    aio write size = 0

    # 2. Memory Cap & Connection Management
    # Caps the maximum number of concurrent child processes. Prevents RAM exhaustion.
    max smbd processes = 6
    # Closes idle connections after 15 minutes instead of the default 60 minutes,
    # reclaiming file descriptors and RAM rapidly.
    deadtime = 15

    # 3. Cryptographic CPU Relief
    # Prevents Samba from initiating or requiring packet signing on non-Time Machine
    # connections (e.g., standard Finder file browsing).
    server signing = no

    # 4. Low-Latency Network Socket Tuning
    # Ensures small metadata packets are dispatched immediately over the wire.
    socket options = TCP_NODELAY

---

3. macOS Client-Side Optimizations (/etc/nsmb.conf)

Adding these parameters to /etc/nsmb.conf on the Mac client disables signing for standard shares and turns off highly intensive, repetitive notifications:

[default]
# Disables SMB client-side packet signing for general shares.
# Note: macOS backupd will still override this and force signing for Time Machine backups,
# but this completely relieves the CPU during standard Finder operations.
signing_required=no

# Disables directory change notifications, saving massive I/O overhead on USB 2.0
notify_off=yes

# Disables negative connection validation
validate_neg_off=yes

---

4. Automation & Robust USB Remount Script

Because USB 2.0 can occasionally drop connections under extreme load, running a lightweight daemon on macOS to automatically handle cooldown periods and resume backups helps tremendously.

The 5-minute cooldown period gives the Time Capsule's USB controller and filesystem time to settle, perform any background journal flushes (fsck), and cleanly remount before starting a new transfer:

#!/bin/bash
# Time Machine Backup Monitor and Cooldown Manager

DEST_UUID="YOUR_TM_DESTINATION_UUID"
COOLDOWN=300   # 5-minute cooldown (in seconds)
POLL=30        # Poll status every 30 seconds

cooldown_start=0

while true; do
  if tmutil status | grep -q 'Running = 1'; then
    echo "$(date): backup running"
    cooldown_start=0
  else
    now=$(date +%s)
    if [ "$cooldown_start" -eq 0 ]; then
      cooldown_start=$now
      echo "$(date): backup stopped/idle — cooldown started"
    fi
    elapsed=$(( now - cooldown_start ))
    if [ "$elapsed" -ge "$COOLDOWN" ]; then
      echo "$(date): cooldown elapsed (${elapsed}s) — starting backup"
      tmutil startbackup -d "$DEST_UUID"
      cooldown_start=0
    else
      echo "$(date): cooldown ${elapsed}/${COOLDOWN}s"
    fi
  fi
  sleep "$POLL"
done

Run this in the background with logging enabled:

nohup ./tm_monitor.sh >> ./tm_monitor.log 2>&1 &

---

5. Measured Results on My Machine

• Active smbd CPU Load: ~6.5% CPU utilization during heavy Time Machine writes (down from peaking or thermal throttling at 100%).
• Active smbd RAM Footprint: Less than 10MB per connection (ensuring safe operations within a tight memory budget).
• Network Throughput: Completely saturates the USB 2.0 bus limit (roughly 30–35 MB/s) without dropping connections, even over extended multi-hour initial backup sessions.

I welcome thoughts on making some of these smb.conf optimizations (like aio read size = 0 / aio write size = 0 and tighter max smbd processes) the default for this repo to help everyone running on legacy hardware out of the box.

[jamesyc]

1. this is all ai generated

2. some of this is good, others are bad idea (no, I am not going to change client side macOS /etc/nsmb.conf settings).

I've added the good ideas in 2ccff2b