# BigD thread calculator > Enter your vCPU count (and whether the system is hyperthreaded) to get the BigD thread count BIG-IP 21.1 derives automatically, per F5's documented formulas, plus the bigd.numprocs override cap and the 15,000-monitor ceiling. - Tool: https://ronutz.com/en/tools/f5-bigd-thread-calculator - Family: Networking --- ## What it does BIG-IP 21.1 rebuilt bigd, the health-monitor daemon, as a single multi-threaded instance able to serve up to 15,000 control-plane monitors, and documented exactly how the automatic thread count is derived from the vCPU count. This tool encodes those two formulas verbatim: enter a vCPU count plus the system type and it returns the thread count the system would derive, the bigd.numprocs manual-override cap, and the monitor ceiling. A bare number computes both formulas side by side. ## The two formulas For hyperthreaded systems, F5's release notes state `Number of BigD Threads = (Number of vCPUs × 6) ÷ 10`, with the rationale that HT cores run at roughly 60% of a real core's performance. For normal (non-HT) systems the formula is `Number of BigD Threads = (Number of vCPUs ÷ 2) − 1`. Where a formula yields a fraction (8 vCPUs hyperthreaded gives 4.8), the release notes state no rounding rule, so the tool shows both the exact value and its whole-thread floor and says so plainly. At 2 vCPUs the normal formula's honest result is 0; bigd still runs, so read that edge as minimal threading, not absence. ## The override and the ceiling The db variable `bigd.numprocs` sets the thread count manually but is capped at the number of available vCPUs; its default 0 means automatic calculation with the formulas above. The multi-threaded daemon supports up to 15,000 control-plane monitors. For sizing context, F5's 21.0 notes recommend keeping bigd at or below 5,000 monitor instances and moving beyond that to In-TMM monitors, which scale to 25,000 with an 8 GB extramb allocation. ## Which platforms are hyperthreaded The formula choice is a platform fact, and F5's own platform documentation settles it. On rSeries, the family splits down the middle: the mid-range and high-end appliances (r5000, r10000, and the r12000 family in F5's sizing tables) run hyperthreading, each Intel core appearing as two vCPUs, while the r2000 and r4000 use a CPU class without hyperthreading and are counted in physical cores only. VELOS is hyperthreaded on both blade types: a tenant's vCPUs are hyperthreads, two per physical core, with BIG-IP tenants using the HT-Split arrangement (K15003) where TMM takes one hyperthread of each core. iSeries and VIPRION also count vCPUs as hyperthreads in F5's sizing language, but neither runs BIG-IP 21.x, so for them the tool shows the mapping as context only. Virtual Edition inherits whatever the hypervisor exposes: check inside the guest (`lscpu`, Thread(s) per core) and pick the matching formula. Type the platform straight into the input: `8 r10900` selects the hyperthreaded formula, `16 r4800` the normal one, `22 velos` hyperthreaded, `8 ve` shows both with the check-your-host note. An explicit `ht` or `normal` word always overrides the platform default, for the case where hyperthreading was disabled in firmware. ## Worked examples `8 ht` yields 4.8 exact, 4 whole threads. `10 ht` lands whole at 6. `16 normal` gives 7. `40 ht` gives 24. `6` alone shows both: 3.6 (floor 3) hyperthreaded, 2 normal. ## Provenance Formulas, cap behavior, and the 15,000 ceiling are verbatim from F5's "New Features in BIG-IP Version 21.1.0" release notes (BigD enhancements for large-scale configurations), fetched 2026-07-08; the 5,000-instance guidance and In-TMM figures are from the 21.0.0 counterpart. The running system's actual thread count is always authoritative. ## Standards and references - [F5 techdocs - New Features in BIG-IP Version 21.1.0: BigD enhancements for large-scale configurations](https://techdocs.f5.com/en-us/bigip-21-1-0/big-ip-release-notes/big-ip-new-features.html) - the multi-threaded single-instance bigd, the 15,000 control-plane monitor ceiling, the two verbatim thread-count formulas (HT: (vCPUs × 6) ÷ 10; normal: (vCPUs ÷ 2) − 1), and the bigd.numprocs manual override capped at the vCPU count with 0 meaning automatic - [F5 clouddocs - rSeries Training: Multitenancy (CPU allocation per model)](https://clouddocs.f5.com/training/community/rseries-training/html/rseries_multitenancy.html) - the platform hyperthreading split: r5000/r10000 (and the r12000 family in the sizing tables) count each Intel core as two vCPUs via hyperthreading, while r2000/r4000 use a CPU class without hyperthreading and count physical cores only - [F5 clouddocs - VELOS Training: Points of Management (tenant vCPUs and HT-Split)](https://clouddocs.f5.com/training/community/velos-training/html/velos_points_of_management.html) - VELOS tenant vCPUs are hyperthreads (two per physical core; 22 vCPUs = 11 physical CPUs), with BIG-IP tenants using HT-Split per K15003; also the iSeries/VIPRION sizing language counting vCPUs as hyperthreads - [F5 K15003 - Data and control plane tasks use separate logical cores under Intel Hyper-Threading](https://my.f5.com/manage/s/article/K15003) - the HT-Split model: on hyperthreaded BIG-IP hardware, TMM runs on one hyperthread of each core while control-plane daemons share the sibling, the architecture behind F5's hyperthreaded-formula rationale ## Related reading - [The BIG-IP 21.x Ops Story: In-Place Upgrades, a 64-Bit Control Plane, and BigD at Scale](https://ronutz.com/en/learn/bigip-inplace-upgrade-and-64bit.md): BIG-IP 21.1 changes how you upgrade (in-place, with a Dry Run compatibility check), what the control plane is built from (64-bit mergeD, Java 21, 64-bit TMSH libraries), how it survives memory pressure (OOM priority for MCPd), how fast it answers (multi-threaded MCPD and a 15,000-monitor multi-threaded BigD), and how it migrates (UCS platform-migrate with validate). Every claim here is from F5's release notes, including the honest limits: in-place is not in-service, and 21.x does not run on iSeries or VIPRION.