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: tuning the locator algorithm #3261

Merged
merged 1 commit into from
Dec 29, 2021

Conversation

driftluo
Copy link
Collaborator

@driftluo driftluo commented Dec 29, 2021

What problem does this PR solve?

The locator algorithm is designed to send a sample of local chains to the remote end, so that both sides can determine the same header of the maximum height of both sides as efficiently as possible, thus completing the header synchronization work faster

As time goes on, the current locator algorithm becomes more and more inapplicable as the chain height increases, and we need a locator algorithm that constantly adjusts itself to the height of the chain. It allows the entire chain to be sampled as much as possible during the sampling process, instead of the lowest sampling point being pulled up step by step as the height increases

This PR relaxes the length of the locator to 52

Check List

Tests

  • Unit test
  • Integration test

Release note

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

@driftluo driftluo requested a review from a team as a code owner December 29, 2021 01:19
@driftluo driftluo force-pushed the tuning-locator-algorithm branch 6 times, most recently from 5fba0d0 to 12876f9 Compare December 29, 2021 03:47
@zhangsoledad
Copy link
Member

bors r= quake,zhangsoledad

@bors bors bot merged commit ae1a959 into nervosnetwork:develop Dec 29, 2021
@driftluo driftluo deleted the tuning-locator-algorithm branch December 30, 2021 00:13
bors bot added a commit that referenced this pull request Nov 15, 2022
3703: feat: tuning the locator algorithm r=driftluo a=driftluo

### What problem does this PR solve?

This previous PR #3261 increased the locator length, but it didn't solve the problem

Take the current height as an example:
Current Algorithm:
[8480818...8480809, 8480807 ...4286507, 92203, 46101, 23050, 11525, 5762]
PR Algorithm:
[8480818...8480809, 8480807 ...4286507, 2143253, 1071626, 535813, 267906, 133953, 66976, 33488, 16744, 8372, 4186]

At the moment `index < step * 2`, too much data is skipped. This will cause a break in the download process, resulting in ibd not being able to be in a multi-node download state as much as possible.

What we want to do is, at the moment `index < step * 2`, turn on the right-shift decrement of the `index` directly, so that the data is not broken as much as possible

ref: #3668

### Check List

Tests

- Unit test
- Integration test

### Release note

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



Co-authored-by: driftluo <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants