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

[synchronizer] Allow different configurations for Narwhal block waiter timeouts in different setups #5210

Open
huitseeker opened this issue Aug 30, 2022 · 0 comments
Labels
narwhal Type: Enhancement New feature or request

Comments

@huitseeker
Copy link
Contributor

In MystenLabs/narwhal#738 we replaced the batch_loader with the block_waiter, so that the block_waiter is now used in its usual context (validator API) as well as in the consensus (in the executor).

There are reasons for that (the batch_loader it replaced was less reliable).

But the fundamental is the block_waiter is a component that has been built with a punctual short lived blocking request in mind (for interfacing with external consensus). Retries were assumed to be cheap there.

In practice, the block_waiter as used in the executor is used to power reliable streaming of transactions from NW consensus to Sui. It retrieves those TXes from the primary's own worker(s) (and failing that, the other workers in the network).

The unhappy path of this retrieval is different: reliability is much more valued than low latency, and retries are more expensive.

Hence it should be possible to have a different config for timeouts in NW + Sui rather than NW + external consensus (right now those timeouts are hard coded constants).

See #5293 for a related issue and a list of current timeouts.

@mwtian mwtian transferred this issue from MystenLabs/narwhal Oct 13, 2022
@mwtian mwtian added Type: Enhancement New feature or request narwhal labels Oct 13, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
narwhal Type: Enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants