With the CPU backend, MUJINA_POOL_FORCED_RATE doesn't produce the configured share rate. At the default MUJINA_CPUMINER_DUTY=50 it finds shares at about half the requested rate, and lower duty slows them proportionally (a forced rate of 6/min at 50% duty gives roughly 3/min). It's also off on any machine whose cores aren't near 5 MH/s. Thread count doesn't matter.
It never corrects itself: the rate is wrong from the start and stays wrong for the whole run, instead of converging as the miner measures its actual hashrate.
This looks like a side effect of a5c3e62 (feat(scheduler): send hashrate to sources only when boards change), which dropped the periodic hashrate broadcast to avoid flooding the pool with difficulty suggestions. The forced-rate wrapper needed that broadcast to learn the measured hashrate. Without it, the wrapper only hears a rate at startup before any hashing happens, so it's stuck on the fallback estimate: a flat per-core guess that ignores duty cycle.
With the CPU backend,
MUJINA_POOL_FORCED_RATEdoesn't produce the configured share rate. At the defaultMUJINA_CPUMINER_DUTY=50it finds shares at about half the requested rate, and lower duty slows them proportionally (a forced rate of 6/min at 50% duty gives roughly 3/min). It's also off on any machine whose cores aren't near 5 MH/s. Thread count doesn't matter.It never corrects itself: the rate is wrong from the start and stays wrong for the whole run, instead of converging as the miner measures its actual hashrate.
This looks like a side effect of
a5c3e62(feat(scheduler): send hashrate to sources only when boards change), which dropped the periodic hashrate broadcast to avoid flooding the pool with difficulty suggestions. The forced-rate wrapper needed that broadcast to learn the measured hashrate. Without it, the wrapper only hears a rate at startup before any hashing happens, so it's stuck on the fallback estimate: a flat per-core guess that ignores duty cycle.