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

Gas estimation: Overestimate based on (actor, method) tuples #8620

Merged
merged 3 commits into from
May 9, 2022

Conversation

Kubuxu
Copy link
Contributor

@Kubuxu Kubuxu commented May 9, 2022

Related Issues

Resolves #8417

Proposed Changes

Have few unique multipleirs apart from the base multipleir

@Kubuxu Kubuxu requested a review from a team as a code owner May 9, 2022 15:03
Copy link
Contributor

@arajasek arajasek left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the PR! I have some qs / suggestions, but good enough to merge!


if builtin.IsStorageMinerActor(act.Code) {
switch msgIn.Method {
case 5:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

case miner.Methods.SubmitWindowedPoSt? (and so on for others)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This corresponds to what is reported in collected statistics so it is easier to verify if it stays as numbers, also as this is very temporary code there is little to no harm to having raw numbers.

If you feel strongly about it I can add comments with method names.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't feel strongly about it, no.

if you want me to double check the values against the collected statistics, i can, but i trust you

if ts.Height() <= build.UpgradeFVM1Height && (build.UpgradeFVM1Height-ts.Height() <= 20) {
transitionalMulti = 2.0

func() {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what do we gain by using an anonymous function here?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It cleans up the error handling.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ah, makes sense

@@ -297,6 +297,47 @@ func gasEstimateGasLimit(

ret := res.MsgRct.GasUsed

transitionalMulti := 1.0
// Overestimate gas around the upgrade
if ts.Height() <= build.UpgradeFVM1Height && (build.UpgradeFVM1Height-ts.Height() <= 20) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How did you pick 20 here?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This gives us 10 minutes of overestimation, there are few reasons I went with 20 epochs.
I would be comfortable with 5 minutes, if we didn’t have tipset system, possible off-by-ones somewhere so on, and I feel like increasing it to 10min has a low cost.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems reasonable -- i don't think there's a "correct" answer here.

@Kubuxu Kubuxu merged commit e1a3ef4 into feat/nv16 May 9, 2022
@Kubuxu Kubuxu deleted the feat/upgrade-gas-est branch May 9, 2022 19:09
@raulk raulk mentioned this pull request May 9, 2022
@Fatman13
Copy link
Contributor

Do nothing. A few epochs worth of messages will fail with Out of Gas, but all messages estimated after the upgrade will be fine. Most critical messages in Lotus have retry mechanisms on failure, so nothing too bad will happen.

Start naively overestimating at some period before the upgrade, by applying (say) a 2x factor. The question would be when to start doing this -- too early and messages that land before the upgrade will pay a lot in overestimation, too late and there will be some messages that were already estimated (and so might fail out of gas).

Start estimating using the actual FVM at some period before the upgrade. The same question about when to start would apply. This won't be too hard, but is probably more work than it's worth.

Is this PR still going for option 2 like the one before?

@Kubuxu
Copy link
Contributor Author

Kubuxu commented May 16, 2022

It is option 2 with an additional tweak for a more precise estimation based on the 80th percentile of some messages.

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

Successfully merging this pull request may close these issues.

3 participants