Hinted election scheduler #3944
Conversation
pwojcikdev
force-pushed
the
prs/hinted-election-scheduler
branch
from
40a1d3b
to
8a73f84
Compare
| * However, it is possible that AEC will be temporarily overfilled in case it's running at full capacity and election hinting or manual queue kicks in. | ||
| * That case will lead to unwanted churning of elections, so this allows for AEC to be overfilled to 125% until erasing of elections happens. | ||
| */ | ||
| return node.active.vacancy () < -(node.active.limit () / 4); |
There was a problem hiding this comment.
I'm not a fan of overfilling though existing behaviour already did this so I don't see a reason to change it here. In the future I think election sets with different limits should be different containers.
| * Creates `count` 1 raw sends from genesis to unique accounts and corresponding open blocks. | ||
| * The genesis chain is then confirmed, but leaves open blocks unconfirmed. | ||
| */ | ||
| std::vector<std::shared_ptr<nano::block>> setup_independent_blocks (nano::test::system & system, nano::node & node, int count) |
There was a problem hiding this comment.
These would probably be useful in the ::test namespace.
There was a problem hiding this comment.
I will move those in separate PR, a new file with all the helpers needs to be created and I don't want to pollute this PR now
|
I think we should be passing a logger into these classes and have the ability to log messages. |
|
I think the hinted scheduler should have some counters counting events. |
|
@dsiganos I added stat logging, should cover all the interesting pathways |
This PR adds an additional election scheduler that prioritises elections by cached tally weight, so elections with the most voting weight already cached (thus under normal conditions more likely to be quickly confirmed) are started first. During testing this demonstrated a significant speedup when backlog is present and nodes are desynchronised.