consider smaller vardiff cycles

[plebhash]

after community testing, we're realizing that vardiff has been causing some confusion on people

• Vardif needs better explanation, and to show progress in the UI, until Vardiff kicks in, users are reporting 'stats are off" type of issues. sv2-ui#42
• label hashrate as estimated with informational tooltips sv2-ui#47

currently, Pool + JDC + tProxy all have hardcoded 60s vardiff cycles:

sv2-apps/pool-apps/pool/src/lib/channel_manager/mod.rs

Lines 565 to 575 in c1cd72e

	async fn run_vardiff_loop(&self) -> PoolResult<(), error::ChannelManager> {
	let mut ticker = tokio::time::interval(std::time::Duration::from_secs(60));
	loop {
	ticker.tick().await;
	info!("Starting vardiff loop for downstreams");
	if let Err(e) = self.run_vardiff().await {
	error!(error = ?e, "Vardiff iteration failed");
	}
	}
	}

sv2-apps/miner-apps/jd-client/src/lib/channel_manager/mod.rs

Lines 1093 to 1103 in c1cd72e

	async fn run_vardiff_loop(&self) -> JDCResult<(), error::ChannelManager> {
	let mut ticker = tokio::time::interval(std::time::Duration::from_secs(60));
	loop {
	ticker.tick().await;
	info!("Starting vardiff loop for downstreams");
	if let Err(e) = self.run_vardiff().await {
	error!(error = ?e, "Vardiff iteration failed");
	}
	}
	}

sv2-apps/miner-apps/translator/src/lib/sv1/sv1_server/difficulty_manager.rs

Lines 32 to 42 in c1cd72e

	pub async fn spawn_vardiff_loop(self: Arc<Self>) {
	info!("Variable difficulty adjustment enabled - starting vardiff loop");
	let mut ticker = tokio::time::interval(std::time::Duration::from_secs(60));
	loop {
	ticker.tick().await;
	info!("Starting vardiff loop for downstreams");
	self.handle_vardiff_updates().await;
	}
	}

---

we should consider making vardiff cycles smaller than 60s

that would allow the UI to display updates more often

two options:

• set a universal constant on stratum-apps with a smaller value (e.g.: 10s)
• make it user configurable via .toml file (and therefore also via sv2-ui wizard)

[plebhash]

from @GitGab19 :

I would make it configurable, and lower the default to 30s.

But also we have to be careful and test for smaller values, to be sure that vardiff works well (eg it doesn't send "too many" updates just because of the smaller interval)

[gimballock]

Alternative: Share-Based Vardiff Triggering

Before settling on a smaller fixed interval (e.g., 10s), consider a more adaptive approach: trigger vardiff evaluation based on share count in addition to wall-clock time.

Why This Works

The statistical reliability of a hashrate estimate depends on sample count, not elapsed time. The relative error of an estimate from N shares is approximately 1/√N:

• 10 shares → ~32% error
• 15 shares → ~26% error
• 100 shares → ~10% error

A miner producing 200 shares/minute (because their difficulty is too low) has enough statistical signal after ~5 seconds. Making them wait 60s wastes time without improving accuracy.

Proposed Implementation

Add share-based triggering as a supplement to (not replacement for) the time-based loop:

1. Add config parameter: min_shares_for_vardiff_eval (default: 15)
2. In handle_submit_shares, after incrementing the counter for accepted shares only, check:

   if shares_since_last_update >= min_shares_for_vardiff_eval {
       // Queue vardiff evaluation for this downstream
   }

3. Keep the existing 60s loop—it's needed to detect hashrate drops (zero-share periods)

Why Keep Both Triggers?

Trigger	Detects	Speed
Share-based	Hashrate too low (shares flooding in)	Fast (seconds)
Time-based	Hashrate too high or miner offline	Slow but reliable

Potential Concerns Addressed

Q: Won't this cause oscillation?
A: No—the existing guards in try_vardiff still apply (15s minimum, percentage thresholds requiring longer time for smaller changes).

Q: What about stale share bursts?
A: Only count accepted shares toward the threshold, not all submissions.

Q: Lock contention on hot path?
A: The threshold check is cheap (integer comparison). If hit, queue the evaluation async rather than blocking the share submission path.

Q: Aggregated mode message spam?
A: Individual downstream difficulty updates can happen immediately, but batch/debounce the upstream UpdateChannel messages (the current 60s loop already provides this batching).

Expected Impact

• Fast miners during initial convergence: 5-15 seconds instead of 60-300 seconds
• Stable miners at correct difficulty: No change (won't hit N shares before time-based evaluation)
• Message rate: Bounded by N (at most one evaluation per 15 shares per miner)

This approach is used in production by some Kaspa pools and significantly improves UX during the initial connection phase—exactly the issue reported in sv2-ui#42.

Happy to help with implementation if this direction is useful.

[Shourya742]

Another point worth highlighting is how we currently handle vardiff. Right now, we hold the lock throughout the entire vardiff processing phase. This effectively blocks any other operations that depend on processing that downstream, causing them to stall while vardiff is being computed.

If we reduce the vardiff interval, this contention will only increase, since the lock will be acquired more frequently, further impacting other flows.

[plebhash]

Q: Lock contention on hot path?
A: The threshold check is cheap (integer comparison). If hit, queue the evaluation async rather than blocking the share submission path.

I'm a bit uncertain about this.

the threshold check on the submit path is cheap, but if a fast miner crosses min_shares_for_vardiff_eval every ~1s, do we then queue a vardiff evaluation every ~1s too?

even if vardiff is effectively a no-op below 15s, those queued evaluations would still contend on the same locks unless we coalesce them to one pending eval per downstream.

[gimballock]

Good point on the coalescing—worth addressing.

The "every ~1s" scenario only happens during initial convergence when difficulty is way off. Once the miner is calibrated, the math works out differently:

At target rate of 20 shares/min, accumulating 15 shares takes ~45 seconds. So in steady state, share-based triggers fire roughly as often as the current 60s loop—not dramatically more.

The key insight is that vardiff converges fast. It's not iteratively refining—each update directly estimates the true hashrate:

H_est_new ≈ H_true × (1 ± measurement_noise)

So you typically land within the 15% deadband after 1-2 iterations. The "fast trigger" phase lasts maybe 5-15 seconds total, not indefinitely.

That said, coalescing to one pending eval per downstream is a clean safeguard and probably worth doing regardless:

if !pending_vardiff_eval.contains(downstream_id) {
    pending_vardiff_eval.insert(downstream_id);
    queue_vardiff_eval(downstream_id);
}

This bounds queue depth to one entry per miner, which handles any edge cases without adding much complexity.

[Shourya742]

I’m currently profiling different vardiff cycle timings across our roles. You can get a quick overview of how 15s, 30s, and 60s intervals affect the Pool, JDC, and Translator here:
Pool and JDC: https://hackmd.io/@mG-mY9sEQie4e8K5Bp-V6g/Hk1U3iojWx
Tproxy: https://hackmd.io/@mG-mY9sEQie4e8K5Bp-V6g/SJdCR2hsWg/edit

[gimballock]

From your tables the lock contention and long times are coming from:

• downstream::handle_downstream_message: 2.63s avg (554% of baseline!)
• channel_manager::handle_template_provider_message: 2.19s avg

Suggesting more frequent evaluations in vardiff should not aggravate lock contention relative to what those functions are doing.