-
Notifications
You must be signed in to change notification settings - Fork 269
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
dynamic block time modifications #983
dynamic block time modifications #983
Conversation
It looks like the volatility is worse when one reduces the target time down to 2 seconds
EDIT: Maybe I just got lucky the first run. It seems the standard deviation is around 0.5s |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
dooope thanks 🙂
elapsed := cs.CommitTime.Sub(cs.StartTime) | ||
nst := cs.config.TargetHeightDuration - elapsed | ||
if nst < time.Millisecond*1 || elapsed < 0 { | ||
nst = time.Millisecond * 1 | ||
} | ||
cs.eventCollector.WritePoint("consensus", map[string]interface{}{ | ||
"elapsed_info": []interface{}{cs.Height, cs.Round, elapsed, nst}, | ||
}) | ||
cs.StartTime = cs.CommitTime.Add(nst) | ||
cs.StartTime = cs.config.NextStartTime(cs.StartTime) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thanks for refactoring this back, I was meaning to move the logic back to NextStartTime
TimeoutPropose: 3000 * time.Millisecond, | ||
TimeoutPropose: 2000 * time.Millisecond, | ||
TimeoutProposeDelta: 500 * time.Millisecond, | ||
TimeoutPrevote: 1000 * time.Millisecond, | ||
TimeoutPrevoteDelta: 500 * time.Millisecond, | ||
TimeoutPrecommit: 1000 * time.Millisecond, | ||
TimeoutPrecommitDelta: 500 * time.Millisecond, | ||
TargetHeightDuration: 3500 * time.Millisecond, | ||
TargetHeightDuration: 3000 * time.Millisecond, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
are these needed for the e2e test to pass or just arbitrary?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just wanted to make it smaller / quicker. Have not strong feelings on what these are set to
when increasing the target time, the volatility seems to decrease! I'm seeing ~.2s in variation for 6s target time, but could just be my machine |
Yeah I think we need to look over a longer range of time (and ideally with 100 nodes and a semi-decent load to see if those factors make an influence) |
…#965) * feat!: consider time already elapsed when waiting after the commit * chore: minor doc changes * chore: try a different default config time * chore: try increasing the config again * fix: use appropriate default time * fix: docs * chore: simplify addition and rename * chore: revert pointless go mod tidy change * chore: consistent config * chore: replace config comments * chore: fix a few remaining round -> height name changes * fix: lingering compile errors from merge * fix: silly bug * fix: use correct next start time * dynamic block time modifications (#983) * chore: remove event collector * Update test/maverick/consensus/state.go Co-authored-by: Callum Waters <[email protected]> * Update test/maverick/consensus/state.go Co-authored-by: Callum Waters <[email protected]> * chore: formatting --------- Co-authored-by: Callum Waters <[email protected]>
* Add `CMT_HOME` (or remove it?) (#983) Closes #982 Added `CMT_HOME` everywhere `CMTHOME` is used. ### Notes to reviewers This could be fixed the opposite way, by removing the only reference to `CMT_HOME` in the code, and also the reference in `UPGRADING.md` (two lines of code). However, the reference in `UPGRADING.md`, which is part of our documentation, is already present in `v0.34.x` (not in `v0.37.x` though!). That's why this PR introduces `CMT_HOME` to work in equal conditions as `CMTHOME`. If reviewers lean toward removing `CMT_HOME` from the doc in `v0.34.x` (and unreleased `v0.38.x` and `main`), I can do it easily. --- #### PR checklist - [x] Tests written/updated - [ ] Changelog entry added in `.changelog` (we use [unclog](https://github.com/informalsystems/unclog) to manage our changelog) - [ ] Updated relevant documentation (`docs/` or `spec/`) and code comments (cherry picked from commit b7be568) # Conflicts: # cmd/cometbft/commands/root_test.go * Revert "Add `CMT_HOME` (or remove it?) (#983)" * Add `CMT_HOME` (or remove it?) (#983) Closes #982 Added `CMT_HOME` everywhere `CMTHOME` is used. This could be fixed the opposite way, by removing the only reference to `CMT_HOME` in the code, and also the reference in `UPGRADING.md` (two lines of code). However, the reference in `UPGRADING.md`, which is part of our documentation, is already present in `v0.34.x` (not in `v0.37.x` though!). That's why this PR introduces `CMT_HOME` to work in equal conditions as `CMTHOME`. If reviewers lean toward removing `CMT_HOME` from the doc in `v0.34.x` (and unreleased `v0.38.x` and `main`), I can do it easily. --- - [x] Tests written/updated - [ ] Changelog entry added in `.changelog` (we use [unclog](https://github.com/informalsystems/unclog) to manage our changelog) - [ ] Updated relevant documentation (`docs/` or `spec/`) and code comments --------- Co-authored-by: Sergio Mena <[email protected]>
…#965) * feat!: consider time already elapsed when waiting after the commit * chore: minor doc changes * chore: try a different default config time * chore: try increasing the config again * fix: use appropriate default time * fix: docs * chore: simplify addition and rename * chore: revert pointless go mod tidy change * chore: consistent config * chore: replace config comments * chore: fix a few remaining round -> height name changes * fix: lingering compile errors from merge * fix: silly bug * fix: use correct next start time * dynamic block time modifications (#983) * chore: remove event collector * Update test/maverick/consensus/state.go Co-authored-by: Callum Waters <[email protected]> * Update test/maverick/consensus/state.go Co-authored-by: Callum Waters <[email protected]> * chore: formatting --------- Co-authored-by: Callum Waters <[email protected]>
Description
Some data from a 4 validator network under transaction load with a 5 second target height:
Would be good to test this under "realistic" network environments i.e. most likely with testground.
PR checklist
.changelog
(we useunclog to manage our changelog)
docs/
orspec/
) and code comments