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

Determine optimizations for Fast Paxos #6

Open
archie opened this issue Sep 13, 2011 · 2 comments
Open

Determine optimizations for Fast Paxos #6

archie opened this issue Sep 13, 2011 · 2 comments
Milestone

Comments

@archie
Copy link
Collaborator

archie commented Sep 13, 2011

No description provided.

@nruth
Copy link
Owner

nruth commented Nov 10, 2011

That means reading the paper, right? ;)

@nruth
Copy link
Owner

nruth commented Dec 3, 2011

Renesse's design makes this redundant in a latency sense, but maybe still useful for throughput (saves messages).

The basic idea is once a proposer (commander/leader) gets a proposal accepted, it uses the notion of being the only proposer in the system (by design, except in case of failure) and skips the prepare phase, going straight into issuing the next vote. Ignoring disk logging (which varies by approach) this would halve the number of quorums needed (and so halve the latency?).

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

No branches or pull requests

2 participants