← Back
Creator Hardware, Storage, NAS Archiving & Technical Workflows

SMB signing or encryption is enabled on a workstation path that was previously tuned for maximum media throughput, materially increasing CPU and latency overhead.

Problem

SMB signing or encryption is enabled on a workstation path that was previously tuned for maximum media throughput, materially increasing CPU and latency overhead.

Solution

Root Cause / Diagnostic:
SMB 3.x includes security features like SMB Signing and SMB Encryption to protect enterprise data from interception. When enabled, every network packet must be cryptographically hashed or encrypted by the CPU before transmission, which adds massive latency and CPU overhead that cuts 10GbE video streaming throughput by 40–60%.

Actionable Fix:
1. Dedicated Video VLAN SMB Security Tuning: In the NAS SMB configuration (`smb.conf`), set `server smb encrypt = desired` (or disabled) and `server signing = no` specifically on trusted, isolated video editing subnets.
2. Workstation Client Security Policy Adjustment: On Windows editing workstations, disable client-side SMB signing requirements via PowerShell (`Set-SmbClientConfiguration -RequireSecuritySignature $false`).
3. Throughput Recovery Benchmark: Execute a network speed test using AJA System Test to confirm that read/write speeds recover from ~400MB/s back to full ~1050MB/s line rate.

Pro Tip:
SMB Signing and Encryption protect office files from hackers, but they crush 10GbE video editing speeds; disable SMB signing on your private studio network to get back full multi-gigabit performance.