HarukaMa / aleo-pool-server

GNU Affero General Public License v3.0
77 stars 79 forks source link

I don't think the difficulty adjustment is reasonable #6

Closed coinsccg closed 2 years ago

coinsccg commented 2 years ago

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?

HarukaMa commented 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.

HarukaMa commented 2 years ago

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.

coinsccg commented 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.

When the difficulty value does not change, the speed will not change, but you also reset it

HarukaMa commented 2 years ago

cmp::Ordering::Less