@Dusk_Foundation Provisioner Mathematics: The CPU Number I Started Watching Instead
I noticed the CPU graph only because one validation window looked wrong. The provisioner had been quiet for most of the hour, then a short burst pushed usage close to the ceiling. Nothing failed. That was almost the problem: the average still looked comfortable.
I started treating the 95th-percentile load as the useful number instead. If the node needs 2.8 effective cores at p95 and I want 30% left unused, the rough sizing becomes 2.8 divided by 0.70, or four cores. Simple enough on paper. But the number gets less tidy once the same machine is handling networking, state work, logging, and whatever small process I forgot was running.
That changes how I think about DUSK provisioner capacity. The question is not whether the server can survive an ordinary consensus round. It is whether validation, ratification, and background work can overlap without turning a short spike into missed participation.
I am slightly wary of fixing one universal headroom target. A stable node with predictable tails is different from one whose p95 and p99 keep separating. I would rather watch that gap across several busy periods, especially after upgrades or changes in network activity. If the tail keeps widening while the average stays flat, that is probably the signal I would trust first.
#dusk $DUSK
I noticed the CPU graph only because one validation window looked wrong. The provisioner had been quiet for most of the hour, then a short burst pushed usage close to the ceiling. Nothing failed. That was almost the problem: the average still looked comfortable.
I started treating the 95th-percentile load as the useful number instead. If the node needs 2.8 effective cores at p95 and I want 30% left unused, the rough sizing becomes 2.8 divided by 0.70, or four cores. Simple enough on paper. But the number gets less tidy once the same machine is handling networking, state work, logging, and whatever small process I forgot was running.
That changes how I think about DUSK provisioner capacity. The question is not whether the server can survive an ordinary consensus round. It is whether validation, ratification, and background work can overlap without turning a short spike into missed participation.
I am slightly wary of fixing one universal headroom target. A stable node with predictable tails is different from one whose p95 and p99 keep separating. I would rather watch that gap across several busy periods, especially after upgrades or changes in network activity. If the tail keeps widening while the average stays flat, that is probably the signal I would trust first.
#dusk $DUSK