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.