Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: notify dummy miner for new work #4126

Merged
merged 1 commit into from
Aug 31, 2023

Conversation

quake
Copy link
Member

@quake quake commented Aug 30, 2023

What problem does this PR solve?

We often use the dummy miner mode for local development, but currently the dummy miner only submits new blocks at configured intervals, when other nodes broadcast the new block, the dummy miner will not switch to the latest tip but continue to submit the old block, so it will become an uncle block.

This behavior is fine in single-node mode, but when we need to simulate the hash rate distribution of multiple nodes for testing, there is no way to simulate this behavior with the dummy miner.

What is changed and how it works?

Tweak the dummy miner inner loop, if there is new tip (pow_hash changed), start working on the new one.

Check List

Tests

  • Manual test (add detailed scripts or steps below)
# init two nodes
./ckb init -c dev --genesis-message dummy-miner-test  --ba-arg miner1-arg
./ckb init -c dev --genesis-message dummy-miner-test  --ba-arg miner2-arg

# add nodes to the whitelist section and config two miners' ckb-miner.toml
# for example, miner1 is 5 sec , miner2 is 9 sec
value = 5000
value = 9000

# start ckb nodes and miners and verify the block cellbase distribution by rpc `get_block_by_number` or check the log manually, it should be distributed as 5 / 14 =~ 35.7% and 9 / 14 =~ 64.3%

Release note

Title Only: Include only the PR title in the release note.

@quake quake requested a review from a team as a code owner August 30, 2023 00:50
@quake quake requested review from zhangsoledad and eval-exec and removed request for a team August 30, 2023 00:50
@eval-exec eval-exec added the t:enhancement Type: Feature, refactoring. label Aug 30, 2023
Comment on lines +97 to +119
fn solve(&mut self, mut pow_hash: Byte32, mut work: Work, nonce: u128) {
let instant = Instant::now();
let delay = self.delay.duration();
loop {
thread::sleep(Duration::from_millis(10));
if instant.elapsed() > delay {
if let Err(err) = self.nonce_tx.send((pow_hash, work, nonce)) {
error!("nonce_tx send error {:?}", err);
}
return;
}
// if there is new work and pow_hash changed, start working on the new one
if let Ok(WorkerMessage::NewWork {
pow_hash: new_pow_hash,
work: new_work,
..
}) = self.worker_rx.try_recv()
{
if new_pow_hash != pow_hash {
pow_hash = new_pow_hash;
work = new_work;
}
}
Copy link
Collaborator

@eval-exec eval-exec Aug 30, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How about this:

use crossbeam_channel::select;

...


    fn solve(&self, pow_hash: Byte32, work: Work, nonce: u128) {
        select! {
            recv(self.worker_rx) -> msg => {
                if let Ok(WorkerMessage::NewWork {
                        pow_hash: new_pow_hash,
                        work: new_work,
                        ..
                }) = msg {
                    if new_pow_hash != pow_hash {
                        pow_hash = new_pow_hash;
                        work = new_work;
                    }
                }
            },
            default(self.delay.duration()) => {
                if let Err(err) = self.nonce_tx.send((pow_hash, work, nonce)) {
                    error!("nonce_tx send error {:?}", err);
                }
                return;

            }
        }
    }

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The current develop branch use a simple thread sleep, and I wanted to keep the code as unchanged as possible, rather than introduce a tokio runtime.

Copy link
Collaborator

@eval-exec eval-exec Aug 30, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wanted to keep the code as unchanged as possible

OK

rather than introduce a tokio runtime.

But self.nonce_tx's type is crossbeam_channel::Sender. We won't need tokio runtime here.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see, I thought it's tokio's select macro, let me change it and test later, thanks.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

after test, I found the code generated by select macro is different, the pow_hash and work vars are not read again, I will keep current code.

@quake quake merged commit 342946b into nervosnetwork:develop Aug 31, 2023
This was referenced Sep 1, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
t:enhancement Type: Feature, refactoring.
Projects
Archived in project
Development

Successfully merging this pull request may close these issues.

2 participants