AI Projects › Hardware limits
None of this ran on enterprise gear. Every limit below shaped a design decision. The transferable skill is getting provable results out of whatever infrastructure a client already has.
The machines, and what each one limited
| Machine | Limit | Response |
|---|---|---|
| Main server (TrueNAS SCALE) | 14 cores and 28 threads, 62 GiB RAM running near 97%, a GPU, 10 GbE. Seven pools, each a single disk with no redundancy. Two flagged degraded, one failed a SMART extended test. The CPU has no SHA instructions. | Inventory before anything else. Rank single-copy data first. One hash pass per disk, all disks in parallel. Database on NVMe, GPU reserved for compression. |
| Rebuilt five-drive NAS | An older appliance rebuilt by hand as a standalone server. “Completed” migrations were 6% to 24% complete. | Treated as a primary source again, with a full database-backed inventory of all five drives. |
| Mini-PC gateway (Windows) | TrueNAS cannot read NTFS, and the mini-PC has only 1 GbE, measured at about 98 MB/s. | Made it the NTFS gateway, mounted read-only over SMB, with large copies scheduled overnight. |
| Forgotten ReadyNAS | One 20 TB disk, one ARM core, 495 days of uptime, no checksums, no root access. Hashing capped at about 30 to 70 MiB/s. | Read-only SMB mount polled every 60 seconds because its CPU sat at 100%. Hashed as its own database volume over several days. |
| Laptop with external GPU | Windows updates and a bugcheck loop interrupted long jobs. | Long jobs moved to the server. The laptop does QA, including an independent re-hash over SMB. |
| AI worker agents | A shared AI usage ceiling. Agents could hold stale instructions. | One image run as several stateless workers with central state. Job cards carry hard rails and every card gets a check-back. |
| Raspberry Pi kiosk | 4 GB RAM and no hardware H.264 decode. | Camera substreams at 640×360 left the device 74% idle. Motion pop-ups pull the high-resolution stream only when needed. |
| Network | The server’s 10 GbE link ran at about 8% during copies. | Diagnosed with measured numbers. The upgrade that moves the needle is a 10 GbE adapter on the mini-PC, not more server ports. |
Status, Nov 10: the GPU compression lane ran from Oct 18 into November. The card has since stopped being detected after power events, so the lane is on hold until it is confirmed working.
Where the bottleneck really was
The obvious suspect was the server. It was not. Copies ran at roughly 8% of the server’s 10 GbE link, because the 1 GbE mini-PC was the slowest device in the path. Diagnosing that before spending money kept the first upgrade cheap and aimed at the right machine. Once the slowest box was known, the schedule could be set around it.
What I take from this into your environment
- List every machine and name the one thing it cannot do.
- Find the slowest device in the path and schedule around it.
- Spend where a measurement says the constraint is.
- Never let an old device’s weakness become the project’s risk.
Source: machine records and the Nov 7 fingerprint report. The GPU status reflects the latest diagnosis and will change as it is resolved.
← The journey | The copy map →