I don't think the difficulty adjustment is reasonable

[coinsccg]

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.current_difficulty as f64) as u64).max(1);
}
_ => {}
}
self.current_difficulty
}

Why reset vecdeque?

[HarukaMa]

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]

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]

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]

cmp::Ordering::Less

[coinsccg]

self.next_difficulty = ((self.current_difficulty as f64 * f64::sqrt(self.speed_1m.speed().await * 20f64)) as u64).max(1);

As long as self.speed_1m.speed().await * 20f64 is greater than 1 and remains unchanged, the value of self.next_difficulty will become larger and larger, will always meet this condition self.current_difficulty.cmp(&self.next_difficulty)

[HarukaMa]

full ctx for ref:

aleo-pool-server/src/server.rs

Lines 64 to 88 in 0000034

	pub async fn add_share(&mut self, value: u64) {
	let now = Instant::now();
	self.speed_1m.event(1).await;
	self.speed_5m.event(value).await;
	self.speed_15m.event(value).await;
	self.speed_30m.event(value).await;
	self.speed_1h.event(value).await;
	self.next_difficulty =
	((self.current_difficulty as f64 * f64::sqrt(self.speed_1m.speed().await * 20f64)) as u64).max(1);
	debug!("add_share took {} us", now.elapsed().as_micros());
	}
	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.current_difficulty as f64) as u64).max(1);
	}
	_ => {}
	}
	self.current_difficulty
	}

The current difficulty target is to keep about 1 share per 20 seconds for each miner. So of course if self.speed_1m.speed().await * 20f64 is greater than 1 the code would want to increase the next difficulty for that miner.

Also note that speed_1m is counted differently as it counts the number of shares submitted by the miner (share / sec), instead of miner's actual speed (proof / sec). I'm planning to change this in the next version.

will always meet this condition self.current_difficulty.cmp(&self.next_difficulty)

Which arm are you referring to?