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

pvf: better approval job scheduling #6401

Open
sandreim opened this issue Nov 7, 2024 · 2 comments
Open

pvf: better approval job scheduling #6401

sandreim opened this issue Nov 7, 2024 · 2 comments
Assignees
Labels
I9-optimisation An enhancement to provide better overall performance in terms of time-to-completion for a task.

Comments

@sandreim
Copy link
Contributor

sandreim commented Nov 7, 2024

We should investigate if under heavy load, the node can avoid wasting CPU time by skipping executing candidates included in finalised blocks.
In theory it should be possible that the pov recovery completes after the inclusion block was finalised, in which case we can simply skip executing the PVF.
Suggested in #5616 (comment)

@sandreim sandreim added the I9-optimisation An enhancement to provide better overall performance in terms of time-to-completion for a task. label Nov 7, 2024
@AndreiEres AndreiEres self-assigned this Nov 15, 2024
@alexggh
Copy link
Contributor

alexggh commented Nov 25, 2024

Thought about this idea as well, one thing to have in mind is that if B1 is finalized on node N1 doesn't not mean it is also finalized on node N2, so whatever solution we pick we need to make sure we don't cancel approvals that other nodes are still waiting for.

@burdges
Copy link

burdges commented Nov 27, 2024

I doubt this matters. If we announce our approval assignment then finality is blocked on us. If we take so long we no-show, then in expectation 2.25 others assignee themselves, and finality is blocked on them, or us, whichever is faster. If they're faster but we're online and still checking, then we've either hit some fluke of networking (unlikely), or else our node has too little bandwidth or too little processing power (likely).

As polkadot's developers we're primarily worried about this last scenario, which means replacing the slow node in the network, not improving its internal performance metrics when its screwing up ours. I think polkadot-fellows/RFCs#119 plays an important role here, but the slow node wasting its resources maybe speeds up it losing nominators & elections.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
I9-optimisation An enhancement to provide better overall performance in terms of time-to-completion for a task.
Projects
Status: Backlog
Development

No branches or pull requests

4 participants