Under-specifying a DSS Pro server is one of the most expensive mistakes in a CCTV deployment — not because the hardware costs more later, but because a CPU-maxed or storage-starved server causes dropped frames, delayed alarms, missed FR matches, and operator complaints that erode confidence in the entire system. Over-specifying wastes budget and makes the proposal uncompetitive. This guide gives you the exact calculations to land in the right place the first time.
We cover five dimensions: CPU, RAM, storage, GPU (for AI workloads), and network bandwidth. Each section includes the calculation formula, a worked example, and a reference table for common deployment sizes.
How DSS Pro Uses Server Resources
Before sizing, it helps to understand what DSS Pro actually does with server hardware — because the load profile is non-obvious:
| Function | CPU load | RAM load | Storage I/O | GPU required |
|---|---|---|---|---|
| Video forwarding to clients | Low–Medium | Low | Low | No |
| Recording to local storage | Low | Low | High (sequential write) | No |
| Motion detection (server-side) | Medium | Low | Low | No |
| Edge AI events (WizMind cameras) | Very low (metadata only) | Low | Low (snapshots) | No |
| Server-side face recognition (FR) | Very high | Medium–High | Medium | Strongly recommended |
| AcuPick / AI event search | High (during search) | Medium | High (random read) | Recommended |
| Text-to-image search (v8.7) | High (during search) | Medium | High | Recommended |
| Person library matching (100K persons) | Low (ongoing) | High (index in RAM) | Low | No (if edge FR) |
| Database operations (events, logs) | Low–Medium | Medium (cache) | Medium (random I/O) | No |
| Client connections (web / thick) | Low per client | Low per client | Low | No |
The key insight: DSS Pro’s base recording and management load is modest. The server load spikes come from AI workloads — specifically server-side face recognition and post-event AI search. If you use edge FR (WizMind cameras) and schedule AI searches during off-peak hours, a mid-range server handles surprisingly large channel counts.
Part 1 — CPU Sizing
Base recording and management (no server-side AI)
For standard DSS Pro deployments using edge AI cameras (WizMind), CPU is rarely the bottleneck. Use this as a starting point:
| Channel count | Minimum CPU | Recommended CPU |
|---|---|---|
| Up to 64 channels | Intel Core i5 (gen 8+), 4 cores | Intel Core i7 (gen 10+), 8 cores |
| 64–200 channels | Intel Core i7 / Xeon E, 8 cores | Intel Xeon Silver / Gold, 12–16 cores |
| 200–500 channels | Intel Xeon Silver, 12 cores | Intel Xeon Gold / AMD EPYC, 16–24 cores |
| 500–1,000 channels | Dual Intel Xeon Gold, 24 cores total | AMD EPYC or dual Xeon Gold, 32+ cores |
| 1,000+ channels | Multi-server deployment (see Part 5) | |
Server-side AI workloads (no GPU)
If you are running server-side face recognition without a GPU, CPU requirements increase dramatically. Rough rule of thumb without GPU: 4 dedicated CPU cores per server-side FR channel. This means 8 server-side FR channels on a 32-core server, with no CPU headroom left for other workloads. This is why GPU is strongly recommended for server-side FR at scale.
CPU clock speed vs core count
DSS Pro’s recording and management services benefit more from higher core count than from higher clock speed. AI workloads benefit from both. For mixed deployments (recording + AI), prefer a modern Xeon or EPYC with 16+ cores at 3.0+ GHz base clock over an older high-clock desktop CPU.
Part 2 — RAM Sizing
RAM calculation formula
Total RAM (GB) = Base OS + DSS Services + Per-Channel + AI Database Cache + Client Sessions
Where:
Base OS: 4 GB (Windows Server 2019/2022)
DSS Services: 8 GB (DSS Pro server processes)
Per-Channel: 64 MB × number of active channels
AI Database Cache: 8 GB (person library up to 50K persons)
16 GB (person library 50K–100K persons)
Client Sessions: 512 MB × number of concurrent client connections
Worked example — 100-channel deployment, 30K person library, 10 concurrent clients
Base OS: 4 GB DSS Services: 8 GB Per-Channel (100 × 64 MB): 6.4 GB AI Database Cache: 8 GB (30K persons) Client Sessions (10 × 0.5): 5 GB ───────────────────────────────── Total: ~31.4 GB → round up to 32 GB
RAM reference table
| Deployment size | Channels | Person library | Concurrent clients | Recommended RAM |
|---|---|---|---|---|
| Small | Up to 64 | None / small | 1–5 | 16 GB |
| Medium | 64–200 | Up to 30K persons | 5–20 | 32 GB |
| Large | 200–500 | 30K–100K persons | 20–50 | 64 GB |
| Enterprise | 500–1,000 | 100K persons | 50–200 | 128 GB |
Important: Always install RAM in matched pairs for dual-channel operation. A 32 GB deployment should use 2 × 16 GB DIMMs, not 1 × 32 GB. Dual-channel RAM provides roughly 30% better memory bandwidth, which noticeably improves AI database query performance.
💬 Need a license or have questions? → Message us on Telegram — free consultation, usually reply within a few hours.
Part 3 — Storage Sizing
Storage is almost always the largest cost component in a DSS Pro deployment. The calculation has three parts: video recording storage, AI event snapshot storage, and database/log storage.
Part 3a — Video Recording Storage
Storage calculation formula
Storage (TB) = (Channels × Bitrate_Mbps × 3,600 × Hours_per_day × Retention_days)
÷ (8 × 1,024 × 1,024)
Simplified form:
Storage (TB) = Channels × Bitrate_Mbps × Hours_per_day × Retention_days × 0.0001055
Bitrate reference — before applying smart codec
| Resolution | Codec | Typical bitrate (Mbps) | Range |
|---|---|---|---|
| 2MP (1080p) | H.264 | 3.0 | 2–4 |
| 2MP (1080p) | H.265 / H.265+ | 1.5 | 1–2 |
| 4MP | H.264 | 5.0 | 4–6 |
| 4MP | H.265 / H.265+ | 2.5 | 2–3 |
| 8MP (4K) | H.264 | 12.0 | 8–16 |
| 8MP (4K) | H.265 / H.265+ | 6.0 | 4–8 |
| 12MP | H.265+ | 9.0 | 6–12 |
| Sub-stream (any res) | H.264/H.265 | 0.5 | 0.3–1.0 |
Smart codec discount: Dahua Smart H.265+ reduces storage by 50–70% compared to standard H.264 in low-motion scenes (parking lots, corridors, empty rooms). Apply a conservative 50% reduction factor when your camera mix is predominantly Smart H.265+ and scenes have low average motion.
Worked example — 100-channel mixed deployment
Camera mix: 60 × 2MP H.265+ cameras at 1.5 Mbps 30 × 4MP H.265+ cameras at 2.5 Mbps 10 × 8MP H.265+ cameras at 6.0 Mbps 24/7 recording, 30-day retention: 60 × 1.5 × 24 × 30 × 0.0001055 = 6.83 TB 30 × 2.5 × 24 × 30 × 0.0001055 = 5.69 TB 10 × 6.0 × 24 × 30 × 0.0001055 = 4.56 TB ───────────────────────────────────────────── Raw total: 17.08 TB Apply Smart H.265+ discount (50%): ~8.54 TB Add 20% overhead (filesystem, OS): ~10.25 TB → Provision: 12 TB usable recording storage (after RAID overhead)
Quick reference — storage per channel, 30-day retention, 24/7 recording
| Camera type | Bitrate | Storage per channel (30 days) | With Smart H.265+ |
|---|---|---|---|
| 2MP H.264 | 3 Mbps | ~972 GB (~1 TB) | ~486 GB |
| 2MP H.265+ | 1.5 Mbps | ~486 GB (~0.5 TB) | ~243 GB |
| 4MP H.265+ | 2.5 Mbps | ~810 GB (~0.8 TB) | ~405 GB |
| 8MP H.265+ | 6 Mbps | ~1.94 TB | ~972 GB |
| FR entrance camera (2MP) | 2 Mbps | ~648 GB | ~324 GB |
Part 3b — AI Snapshot and Event Storage
DSS Pro stores face capture snapshots, AI event thumbnails, and alarm snapshots separately from video. This is often overlooked in sizing calculations but can add up significantly on high-traffic FR deployments.
AI Snapshot Storage (GB/month) = FR_channels × Detections_per_hour × 24 × 30 × Snapshot_size_KB / 1,048,576
Typical values:
Detections per hour: 200–500 (entrance camera, business hours)
50–100 (low-traffic corridor)
Snapshot size: ~30–80 KB per face capture (JPEG, 200×200 px)
Example: 8 FR cameras, 300 detections/hour average, 60 KB per snapshot:
8 × 300 × 24 × 30 × 60 / 1,048,576 = ~9.9 GB/month
AI snapshot storage is manageable — typically 5–15 GB per month per active FR camera. Set a retention policy for AI snapshots in Storage Management → AI Snapshot Retention to prevent unbounded growth. 90 days is a common retention window for investigations.
Part 3c — Database and Log Storage
DSS Pro’s SQL database stores event logs, alarm history, access control records, and configuration data. This is relatively small but benefits from fast storage:
- Small deployments (<100 channels): 50–100 GB, 1 year of events
- Medium deployments (100–500 channels): 200–500 GB, 1 year of events
- Large deployments (500+ channels, FR active): 500 GB – 2 TB, 1 year of events
The database and DSS Pro application should reside on SSD storage, separate from video recording drives. A dedicated 500 GB NVMe SSD for the OS, DSS Pro installation, and database covers most deployments up to 500 channels.
Storage architecture recommendations
| Storage tier | Content | Drive type | RAID level |
|---|---|---|---|
| System / Database | OS, DSS Pro app, SQL database | NVMe SSD or SATA SSD | RAID 1 (mirror) |
| Video recording | Main stream video files | NAS/surveillance-grade HDD (Seagate SkyHawk, WD Purple) | RAID 5 or RAID 6 |
| AI snapshots | Face captures, event thumbnails | SATA SSD or fast HDD | RAID 1 or RAID 5 |
Always use surveillance-grade HDDs (Seagate SkyHawk, WD Purple, or equivalent) for video recording. Standard desktop drives are not rated for the continuous write cycles that 24/7 video recording generates and fail prematurely in this workload.
RAID is not a backup. RAID protects against drive failure but not against controller failure, accidental deletion, or ransomware. Maintain a separate backup of the DSS Pro configuration database.
Part 4 — GPU Sizing for AI Workloads
GPU is optional for basic DSS Pro deployments using edge AI cameras. It becomes necessary when using server-side face recognition, running AcuPick searches over large video archives, or enabling text-to-image search on multiple channels simultaneously.
When you need a GPU
| Workload | GPU required? | Notes |
|---|---|---|
| Edge FR (WizMind cameras only) | No | All AI processing on camera; server receives metadata only |
| Server-side FR, 1–4 channels | Optional (CPU possible) | CPU-only works but will consume 4–8 cores; latency higher |
| Server-side FR, 5–16 channels | Strongly recommended | Without GPU, server CPU will saturate |
| Server-side FR, 16+ channels | Required (multiple GPUs) | Plan 1 GPU per 8–12 FR channels |
| AcuPick / post-event AI search | Recommended | GPU dramatically reduces search time over large archives |
| Text-to-image search (v8.7) | Recommended | CPU-only mode supported but slow |
GPU selection guide
| Deployment scale | Server-side FR channels | Recommended GPU | VRAM |
|---|---|---|---|
| Small | 1–4 | NVIDIA RTX 3060 / RTX 4060 | 8–12 GB |
| Medium | 4–12 | NVIDIA RTX 3080 / RTX 4080 or Quadro RTX 4000 | 16 GB |
| Large | 12–24 | NVIDIA RTX 4090 or Tesla T4 / A16 | 24 GB+ |
| Enterprise | 24+ | Multiple NVIDIA A10 or A40 (datacenter series) | 24 GB per card |
Note on consumer vs professional GPUs: Consumer GeForce cards (RTX 3080, RTX 4090) work with DSS Pro and offer excellent price-to-performance for FR workloads. Quadro/professional cards (A10, A40) provide ECC memory, better thermal design for 24/7 operation, and longer driver support lifecycles — worth the premium for mission-critical deployments.
GPU driver requirement: DSS Pro uses CUDA for GPU-accelerated AI. Install the latest stable NVIDIA driver and CUDA toolkit before configuring server-side FR. Mismatched CUDA versions are a common cause of GPU not being detected by DSS Pro AI services.
Part 5 — Network Bandwidth Sizing
Incoming bandwidth (cameras → DSS Pro server)
Incoming bandwidth (Mbps) = Sum of all camera main-stream bitrates Example: 100 cameras at average 2.5 Mbps each = 250 Mbps incoming
Use a 1 GbE NIC for up to ~800 Mbps of camera traffic (leaving headroom). Use a 10 GbE NIC for deployments where total incoming bitrate exceeds 600 Mbps. DSS Pro supports up to 600 Mbps incoming bandwidth per server on a single 1 GbE connection in the official spec; real-world headroom suggests 10 GbE above 300+ channels at high bitrate.
Outgoing bandwidth (DSS Pro server → clients)
Outgoing bandwidth (Mbps) = Concurrent clients × Streams per client × Sub-stream bitrate Example: 10 operators, each viewing 4 cameras on sub-stream at 0.5 Mbps each: 10 × 4 × 0.5 = 20 Mbps outgoing (modest — sub-stream is efficient) With playback (main stream) requests: Add 2–5 Mbps per concurrent playback stream
Client-to-server traffic is generally not the bottleneck unless many operators are simultaneously viewing live main-stream footage or pulling simultaneous playback. Configure clients to default to sub-stream for live view; main-stream should be on-demand only.
NIC configuration recommendations
| Deployment size | Total incoming bitrate | NIC recommendation |
|---|---|---|
| Up to 64 channels (2MP H.265+) | ~96 Mbps | 1 GbE (single port) |
| 64–200 channels | 96–500 Mbps | 1 GbE bonded (2 × 1GbE) or 10 GbE |
| 200–500 channels | 500 Mbps – 1.2 Gbps | 10 GbE (mandatory) |
| 500+ channels | 1.2 Gbps+ | Multiple 10 GbE or 25 GbE; consider multi-server |
Separate camera network from operator/client network where possible. Use two NICs on the DSS Pro server — one on the camera VLAN (incoming video) and one on the operations network (client access). This prevents video ingestion traffic from competing with operator access during high-load events.
Part 6 — Complete Sizing Examples by Deployment Type
Example A — Small Office / Retail (32 cameras)
| Component | Specification | Notes |
|---|---|---|
| Cameras | 32 × 2MP H.265+ at 1.5 Mbps | No FR requirement |
| Retention | 30 days, 24/7 | |
| Concurrent clients | 2 | |
| CPU | Intel Core i5-12400 (6 cores) | |
| RAM | 16 GB DDR4 | |
| System SSD | 256 GB NVMe SSD | OS + DSS Pro + database |
| Video storage | 4 TB × 2 HDD in RAID 1 | 32 × 0.5 TB × 50% smart codec = ~8 TB raw → RAID 1 = 4 TB usable. Add buffer → 2×4TB |
| GPU | Not required | |
| Network | 1 GbE | 32 × 1.5 Mbps = 48 Mbps incoming |
| Estimated total storage cost | ~8 TB usable |
Example B — Mid-size Commercial Building (150 cameras, 8 FR channels)
| Component | Specification | Notes |
|---|---|---|
| Cameras | 140 × 4MP H.265+ at 2.5 Mbps 10 × WizMind FR cameras at 2 Mbps |
Edge FR on WizMind cameras |
| Retention | 60 days, 24/7 | |
| Person library | 5,000 persons | |
| Concurrent clients | 10 | |
| CPU | Intel Xeon Silver 4314 (16 cores, 2.4 GHz) | |
| RAM | 32 GB ECC DDR4 (2 × 16 GB) | |
| System SSD | 500 GB NVMe SSD (RAID 1 mirror) | OS + DSS Pro + database |
| Video storage (raw calc) | 140 × 2.5 × 24 × 60 × 0.0001055 = 53.2 TB 10 × 2.0 × 24 × 60 × 0.0001055 = 3.0 TB Total raw: 56.2 TB Smart H.265+ (50%): ~28 TB +20% overhead: ~33.6 TB |
|
| Video storage (provisioned) | 6 × 8 TB surveillance HDD in RAID 6 | 48 TB raw → ~32 TB usable with RAID 6 overhead. Fits with margin. |
| AI snapshot storage | 500 GB SSD | 10 FR cameras × ~5 GB/month × 90-day retention |
| GPU | Not required (edge FR on WizMind) | Add RTX 4060 if AcuPick search speed matters |
| Network | 10 GbE (camera NIC) + 1 GbE (client NIC) | 150 channels × ~2.4 Mbps avg = ~360 Mbps incoming |
Example C — Enterprise / Industrial (500 cameras, 30 FR channels, server-side)
| Component | Specification | Notes |
|---|---|---|
| Cameras | 470 × mixed 2MP–8MP H.265+ 30 × server-side FR channels (4MP) |
Server-side FR — GPU mandatory |
| Retention | 90 days, 24/7 | |
| Person library | 50,000 persons | |
| Concurrent clients | 40 | |
| CPU | Dual Intel Xeon Gold 6330 (28 cores each = 56 total) | |
| RAM | 128 GB ECC DDR4 (8 × 16 GB) | |
| System / DB storage | 2 × 1 TB NVMe SSD in RAID 1 | |
| Video storage | ~200 TB usable (calculated per camera mix, 90-day retention) | Use external NAS (iSCSI) or SAN — internal bays insufficient at this scale |
| GPU | 3 × NVIDIA RTX 4080 (16 GB VRAM each) | ~10 FR channels per GPU; 3 GPUs cover 30 FR channels with headroom |
| Network | 2 × 10 GbE (camera, bonded) + 10 GbE (client) + 10 GbE (NAS/iSCSI) | 500 channels at avg 3 Mbps = 1,500 Mbps — requires bonded 10 GbE or single 25 GbE |
| Failover | Secondary DSS Pro server (hot standby) | Required at this scale; replicate DB to standby in real time |
💬 Need a license or have questions? → Message us on Telegram — free consultation, usually reply within a few hours.
Part 7 — Virtualization (VMware / Hyper-V)
DSS Pro can run on virtualized infrastructure with some important caveats:
- VMware ESXi is the best-supported hypervisor. Hyper-V is functional but less tested by Dahua.
- CPU over-commitment: Do not over-commit CPU on the DSS Pro VM. Allocate dedicated vCPUs, not shared ones. CPU scheduling delays on shared vCPUs cause recording gaps and delayed alarm processing.
- Storage I/O: Assign dedicated datastores (not shared LUNs) for video recording. DSS Pro’s sequential write pattern can saturate shared datastores and impact other VMs.
- GPU passthrough: For server-side FR on VMware, use GPU passthrough (not vGPU) to give the DSS Pro VM exclusive access to the GPU. vGPU sharing introduces latency that degrades FR real-time performance.
- Network: Use VMXNET3 adapters (not e1000) for video ingestion NICs — VMXNET3 has significantly lower CPU overhead for high-throughput traffic.
- Snapshot caution: Do not use VMware snapshots on a running DSS Pro VM. Live snapshots can corrupt the DSS Pro database, which uses SQLite and SQL Server files that are not crash-consistent under hypervisor snapshot.
Part 8 — Storage Calculator (Quick Reference)
Use this table to estimate storage for your specific channel count, bitrate, and retention period without manual calculation. All values assume 24/7 recording and include a 20% overhead buffer for filesystem and OS. Values reflect after Smart H.265+ compression (50% reduction applied).
| Channels | Avg bitrate/ch | 14-day retention | 30-day retention | 60-day retention | 90-day retention |
|---|---|---|---|---|---|
| 16 | 1.5 Mbps | 1.0 TB | 2.2 TB | 4.4 TB | 6.5 TB |
| 32 | 1.5 Mbps | 2.0 TB | 4.3 TB | 8.6 TB | 13.0 TB |
| 64 | 2.0 Mbps | 5.4 TB | 11.5 TB | 23.0 TB | 34.6 TB |
| 100 | 2.5 Mbps | 10.6 TB | 22.6 TB | 45.2 TB | 67.8 TB |
| 200 | 2.5 Mbps | 21.1 TB | 45.2 TB | 90.4 TB | 135.6 TB |
| 300 | 2.5 Mbps | 31.7 TB | 67.8 TB | 135.6 TB | 203.4 TB |
| 500 | 3.0 Mbps | 63.5 TB | 135.8 TB | 271.6 TB | 407.4 TB |
To use this table for non-H.265+ cameras: double the values (removing the 50% codec discount). For mixed deployments, calculate each camera group separately using the formula and sum.
Dahua DSS Pro Server Sizing Calculator
Before you read the best practices, you can use the calculation tool below to estimate the server specifications required for your project. Enter the number of cameras, resolution, retention time, and AI parameters.
For more accurate calculations or expert advice, contact us on Telegram.
Common Sizing Mistakes
- Sizing for peak bitrate, not average bitrate. Cameras encode at variable bitrate — a camera at a busy intersection at midnight uses a fraction of its daytime bitrate. Use average bitrate (typically 50–60% of the configured maximum) for storage calculations, not the maximum configured value.
- Forgetting RAID overhead in storage provisioning. RAID 5 loses 1 drive equivalent; RAID 6 loses 2. A 4 × 8 TB array in RAID 5 gives 24 TB usable, not 32 TB. Always calculate usable capacity after RAID, not raw.
- Single NIC for both camera and client traffic. Operator playback and live view compete with recording ingestion on a shared NIC. Separate them at the physical layer for reliability.
- Desktop CPUs in production servers. Desktop CPUs (i5, i7) lack ECC memory support, have thermal designs built for burst loads not sustained operation, and have lower PCIe lanes for storage and GPU. Use server-class CPUs (Xeon, EPYC) for deployments above 64 channels or any deployment with SLA requirements.
- Not separating OS/database from video storage. Running the OS and DSS Pro database on the same HDDs used for video recording causes severe I/O contention. The database needs random I/O performance (SSD); video recording needs sequential throughput (HDDs). Always separate them.
- Ignoring AI snapshot storage. FR cameras can generate 5–15 GB of snapshot data per month per camera. At 20 FR cameras and 90-day retention, that is 300 GB+ that will fill up a system drive if not directed to the right storage pool.
- Planning for today’s channel count only. DSS Pro deployments grow. Size storage and CPU with at least 30% headroom above current requirements. Adding storage to a running system mid-deployment is disruptive and often more expensive than getting it right initially.
💬 Need a license or have questions? → Message us on Telegram — free consultation, usually reply within a few hours.
Frequently Asked Questions
Can DSS Pro run on a NAS device (Synology, QNAP)?
DSS Pro requires a Windows Server or Windows 10/11 environment — it cannot be installed directly on a NAS OS. However, a NAS can serve as the storage target for DSS Pro via iSCSI or SMB. The DSS Pro server software must run on a dedicated Windows machine; the NAS provides the video storage volume. This is a common and cost-effective architecture for medium deployments where a full server rack is not practical.
How much does storage cost for a 100-channel, 30-day deployment?
At an average 2.5 Mbps per channel with Smart H.265+, a 100-channel 30-day deployment needs roughly 22–25 TB of usable video storage. Using Seagate SkyHawk 8 TB drives in a RAID 5 array (4 × 8 TB = 24 TB usable), hardware cost for drives alone is approximately $400–600 USD as of 2026. The RAID controller and enclosure add to this depending on whether you use a standalone server with HBA or an external NAS shelf.
Does DSS Pro support iSCSI storage for large deployments?
Yes. DSS Pro 8.7 supports iSCSI for network-attached storage, which is the recommended approach for deployments above 200 channels where internal drive bays are insufficient. Configure the iSCSI LUN as a local volume in Windows (via iSCSI initiator) and then assign it as a recording volume in DSS Pro’s Storage Management. DSS Pro treats it identically to a local drive; no special configuration is needed in the software beyond assigning the volume.
What happens when storage fills up? Does DSS Pro overwrite old footage?
Yes — DSS Pro uses a circular recording policy by default. When the assigned storage volume reaches its capacity threshold (configurable, default 90%), the oldest recording files are automatically deleted to make room for new recordings. This is expected behavior. If you need to preserve footage beyond the circular overwrite window, configure an archiving rule to copy recordings to a secondary storage location before they are eligible for overwrite.
Is a separate database server needed for large DSS Pro deployments?
DSS Pro installs and manages its own database (SQL Server Express by default; full SQL Server for large deployments). For deployments up to ~500 channels, the built-in database running on the DSS Pro server is sufficient. Above 500 channels with high event volumes (active FR, access control), a dedicated database server improves event query and alarm processing performance. DSS Pro supports connection to a remote SQL Server instance via standard connection string configuration in the DSS Pro installation wizard.
How do I calculate the server specs for a DSS Pro deployment with both recording and FR?
Calculate each workload separately, then combine with a 20% headroom buffer. Use the RAM formula from Part 2 for memory, the storage formulas from Part 3 for drives, and the GPU table from Part 4 for AI. CPU: start from the base recording table and add GPU-offloaded AI; if using edge FR, the CPU addition is minimal. The worked examples in Part 6 cover common mixed-workload scenarios.
Related Guides
- DSS Pro Facial Recognition Setup — Complete Step-by-Step Guide
- SmartPSS vs DSS Express vs DSS Pro — Which Platform Should You Choose?
- HikCentral Professional vs DSS Pro — Complete VMS Comparison
Get a license — free consultation
Pricing depends on version and number of users. Message us on Telegram and we’ll reply with an exact quote — no commitment required.
|
✓
20+ years experience
Software engineers with a long track record
|
⚡
Delivered within 24h
Your license is sent within one business day
|
↩
Money-back guarantee
If the license doesn’t work, we refund in full
|
Usually reply within a few hours — free consultation, no upfront payment
