channels_sv2::vardiff::classic::VardiffState::try_vardiff returns:
Ok(Some(new_hashrate)) when an update occurs
Ok(None) when conditions don’t warrant an update
Err for actual processing errors
we need to add the following methods to channels_sv2::server::{standard,extended}:
set_stable_hashrate(bool: stable_hashrate)
get_stable_hashrate() -> bool
the application layer would be responsible for calling these on its try_vardiff tasks, by following this logic:
match try_vardiff(...) {
Ok(Some(new_hashrate)) => channel.set_stable_hashrate(false),
Ok(None) => channel.set_stable_hashrate(true),
Err(_) => {},
}
that way, stratum-apps can poll get_stable_hashrate to expose HTTP APIs that allow sv2-ui to display informations as suggested by @average-gary :
note: I don't think stratum-mining/sv2-apps#396 has much to do with this
at best, making vardiff cycles shorter (which is not a low-hanging fruit on sv2-apps) only would make the proposed vardiff progress indicator converge to ✅ a bit faster, which is good but not the point to be unblocked here
channels_sv2::vardiff::classic::VardiffState::try_vardiffreturns:Ok(Some(new_hashrate))when an update occursOk(None)when conditions don’t warrant an updateErrfor actual processing errorswe need to add the following methods to
channels_sv2::server::{standard,extended}:set_stable_hashrate(bool: stable_hashrate)get_stable_hashrate() -> boolthe application layer would be responsible for calling these on its
try_vardifftasks, by following this logic:that way,
stratum-appscan pollget_stable_hashrateto expose HTTP APIs that allowsv2-uito display informations as suggested by @average-gary :note: I don't think stratum-mining/sv2-apps#396 has much to do with this
at best, making vardiff cycles shorter (which is not a low-hanging fruit on
sv2-apps) only would make the proposed vardiff progress indicator converge to ✅ a bit faster, which is good but not the point to be unblocked here