How the pool works
There is no server that sims. Simhive splits every sim into batches across members' PCs, measures what each machine delivers in SimulationCraft iterations, and uses that score only when the pool is busy.
There is no server that sims. Simhive itself is a small broker: it keeps the list of machines, hands out batches and keeps the score. The computing power is the members' own PCs. Everyone runs the same Simhive app, and it does two things.
- When you sim, your job is cut into batches (a Droptimizer of 200 items becomes a few dozen batches) and spread over every machine online, faster machines getting bigger batches. Each machine sims its batch with SimulationCraft and sends the numbers back; your Simhive stitches them into one report. A Droptimizer that takes 20 minutes alone takes a couple of minutes on ten machines.
- When you don't, your PC takes batches for the others, with the threads you allow, never while WoW runs (unless you say so), never for anything but SimulationCraft on plain text. Your own machine also helps with your own sims like any other.
Nobody has to leave a PC on. The app does nothing at all while it is closed, and a member who only ever sims and never lends still gets served, last in line when it is crowded, that is all.
Limits #
A sim may be long (a 30-minute dungeon run is fine) but not endless: at most 1800 s of fight, 200,000 iterations per profile, target error no finer than 0.05 %, 20 targets, 1000 profilesets, and a total budget of simulated seconds that refuses the combination that could not finish in reasonable time. Every machine kills a single batch after 20 minutes. These rules are checked on the pool and again on each machine; no client can talk its way past them.
What is measured, and how #
- The unit is SimulationCraft iterations of a five-minute fight. Every batch a machine returns says how many iterations it ran and how long the fight was; an iteration of a 35-minute dungeon route counts seven times a Patchwerk one, so lending your evening to route sims is credited for the work, not the count. That number is booked to the member who owns the machine as given, and to the member whose sim it was as used. Iterations are the one thing every batch reports and nothing can inflate: a fast machine that returns a batch in 2 s and a slow one that needs 20 s both delivered the same iterations. The fast one simply gets more batches, so it earns more per hour. Core count, clock speed or what a machine claims about itself never enter the score.
- Standby. A machine that is online and ready while the pool has nothing to hand out earns a small credit: 5 % of what it would have simmed at its measured speed. It rewards being there at 3 a.m. without rewarding it as much as real work.
- Speed (it/s) is measured on real batches only, a rolling average of what the machine actually delivered, and is used to size batches, not to score. Until a machine has done a few real batches it shows "not measured".
- Score = given + standby, over a rolling 30-day window; older days fall out. Your own machines simming your own jobs are neutral: nothing given, nothing used.
What the score does, and does not #
Off-peak it does nothing: whoever sims gets the whole pool. Only when more jobs are queued than the pool can run at once, the score orders them. Every member's weight is their score plus a free allowance of 150,000 iterations (about one Droptimizer, so a newcomer is not stuck behind everyone), and batches go to waiting jobs in proportion to weight × time waited. A heavy contributor is served first, but nobody waits forever. The score never limits how much you may sim, never blocks anyone, and there is nothing to buy.
Your standing is in the Pool panel of your app: score, given, used, standby, rank. The scores page ranks members by what they gave; nobody sees what anybody else simmed, or used.
One SimulationCraft build for everyone #
The pool pins one SimulationCraft commit, moved nightly, and every machine fetches that exact build from a public build channel, checksum verified, never from the pool. A Droptimizer split over ten machines must give one answer, so by design nobody can stay on another build.