Understanding Node Benchmarks

Understanding Node Benchmarks

Flux node benchmarks are automated hardware performance tests that verify your server meets the minimum requirements for its registered tier. Unlike many blockchain networks that only check specifications once at registration, Flux continuously validates node hardware through benchmarks that run every six hours. This ensures the network maintains consistent quality of service for decentralized application hosting.

What Benchmarks Test

The benchmark suite evaluates four key hardware dimensions. Each test produces a numeric score that must meet or exceed the minimum threshold for the node tier. All four tests must pass for a benchmark to be considered successful.

1. 1

   EPS — Events Per Second (CPU Benchmark)

   Measures raw CPU computational performance by executing a standardized workload and counting the number of events processed per second. This is the primary CPU performance indicator and correlates with processor speed, core count, and architecture efficiency.

2. 2

   RAM Test

   Verifies that the node has the minimum required amount of usable RAM. This test checks total available memory, not total installed memory — swap space and memory reserved by the OS or other processes is excluded.

3. 3

   SSD Write Speed Test

   Measures disk write performance in MB/s by writing a test file to storage. This test is particularly sensitive to storage type (HDD vs SATA SSD vs NVMe) and is one of the most common causes of benchmark failure, especially on shared VPS environments.

4. 4

   Network Speed (Download/Upload)

   Tests sustained download and upload bandwidth by transferring data to and from test endpoints. Both upload and download speeds must meet the minimum threshold for the tier.

Minimum Benchmark Thresholds

Each tier has specific minimum scores that must be met. These thresholds are enforced by the network and may be adjusted over time as hardware standards evolve.

Benchmark Frequency and Scheduling

Benchmarks run automatically every 6 hours (4 times per day). The timing is offset per node, so not all nodes benchmark simultaneously. Each benchmark cycle records results to the local FluxOS database, and the results are shared with the network. You can also trigger a manual benchmark at any time through the FluxOS UI or API, though manual benchmarks do not replace scheduled ones.

What Happens When a Benchmark Fails

When a node fails a benchmark, it enters a DOS (Denial of Service) state. In DOS state the node is flagged as non-compliant by the network. Key consequences include:

• •The node is removed from the reward queue and stops earning FLUX rewards.
• •The node is not eligible to host applications — existing app instances may be migrated away.
• •The node remains in DOS state until it passes a subsequent benchmark cycle.
• •Prolonged DOS state can negatively impact PNR (Progressive Node Rewards) score, reducing your reward multiplier even after recovery.
• •If the node remains in DOS for an extended period, it may be removed from the deterministic node list entirely, requiring a restart from the wallet.

Checking Benchmark Status

There are several ways to check your node benchmark results and status.

# View the latest benchmark results
fluxbench-cli getbenchmarks

# Example output:
# {
#   "status": "passed",
#   "eps": 342.57,
#   "ram": 31.28,
#   "ssd": 487.23,
#   "ddwrite": 487.23,
#   "download_speed": 812.45,
#   "upload_speed": 445.32
# }

You can also check benchmark status through the FluxOS UI at http://YOUR_IP:16126, which displays benchmark results in a user-friendly dashboard. Additionally, the FluxOS API provides programmatic access to benchmark data at http://YOUR_IP:16127/flux/benchmarks.

Common Causes of Benchmark Failures

1. 1

   Shared/oversubscribed VPS resources

   Many budget VPS providers oversell CPU and I/O capacity. Your "4 cores" might share physical cores with other tenants, leading to inconsistent EPS scores. Choose providers offering dedicated CPU cores.

2. 2

   CPU throttling and power management

   Some servers have aggressive power management that reduces CPU frequency during low loads. When the benchmark triggers, the CPU may not ramp up fast enough. Disable CPU frequency scaling if you have bare-metal access.

3. 3

   Disk I/O contention

   The SSD write test is highly sensitive to I/O contention. If other tenants on the same physical host are performing heavy disk operations, your write speeds can drop significantly. NVMe storage and dedicated servers mitigate this.

4. 4

   Bandwidth throttling or data caps

   Some providers throttle bandwidth after reaching monthly data caps. Ensure your hosting plan provides consistent, unmetered bandwidth at the required speeds.

5. 5

   Insufficient RAM headroom

   Running applications, the OS, Docker containers, and MongoDB all consume RAM. If your total RAM barely meets the tier minimum, the usable RAM reported in benchmarks may fall below the threshold.

6. 6

   Background processes during benchmarks

   System updates, Docker image pulls, log rotation, or cron jobs running during benchmark windows can consume resources. Schedule maintenance tasks outside benchmark windows when possible.

Improving Benchmark Scores

• •Upgrade to NVMe storage — The single most impactful improvement for SSD write scores. NVMe can improve write speeds by 3-5x over SATA SSD.
• •Use dedicated CPU cores — Avoid "burstable" or "shared" CPU plans. Look for providers offering dedicated vCPU allocations.
• •Provision extra RAM — Add 2-4 GB above the tier minimum to account for OS and service overhead.
• •Choose quality hosting providers — Established providers with enterprise-grade hardware deliver more consistent benchmark results than ultra-budget options.
• •Minimize background services — Run only FluxOS and its required services on the node. Avoid hosting other applications or services on the same server.
• •Monitor and trend your scores — Track benchmark results over time to identify degradation early, before scores drop below thresholds.