Closed coinsccg closed 2 years ago
If the difficulty is just increased, there will be lower difficulty share still in the counter and it will affect the calculation. You can try removing that reset line and see what will happen after a difficulty increase.
That said, this was written before there are a good speedometer, so I’m planning to rewrite that part using proper miner speed tracking.
Closing the issue here, feel free to reopen if you have further questions.
Oh, one more thing - there is a major rewrite going on with significant changes on database and prover protocol so I'd recommend not trying to deploy it right now.
If the difficulty is just increased, there will be lower difficulty share still in the counter and it will affect the calculation. You can try removing that reset line and see what will happen after a difficulty increase.
That said, this was written before there are a good speedometer, so I’m planning to rewrite that part using proper miner speed tracking.
Closing the issue here, feel free to reopen if you have further questions.
When the difficulty value does not change, the speed will not change, but you also reset it
cmp::Ordering::Less
pub async fn next_difficulty(&mut self) -> u64 { match self.current_difficulty.cmp(&self.next_difficulty) { cmp::Ordering::Less => { self.speed_1m.reset().await; // ?????? self.current_difficulty = self.next_difficulty; } cmp::Ordering::Greater => { self.current_difficulty = ((0.9 * self.currentdifficulty as f64) as u64).max(1); } => {} } self.current_difficulty }
Why reset vecdeque?