-
Notifications
You must be signed in to change notification settings - Fork 101
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
Fresh weights #433
Fresh weights #433
Conversation
those big numbers here:
looks ok, because previous values were just some "random" weights: request_revenue_info_at:
notify_revenue:
on_new_timeslice:
|
We should do for all runtimes as part of the release though? |
Donal wanted coretime-polkadot and polkadot and I wanted AssetHubs/BridgeHubs. |
// Measured: `2848` | ||
// Estimated: `6313` | ||
// Minimum execution time: 92_241_000 picoseconds. | ||
Weight::from_parts(93_731_000, 0) | ||
.saturating_add(Weight::from_parts(0, 6313)) | ||
.saturating_add(T::DbWeight::get().reads(7)) | ||
.saturating_add(T::DbWeight::get().writes(5)) |
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.
@eskimor I now think you were right all along, I'm going to increase all the buffers on the coretime side. The 5% buffer I have right now makes me uncomfortable with possible increases as big as this (multiple additional writes) from one release to the next, we could get into a scenario where relay or coretime chain needs to be updated before the other. I'm going to just slap a 100% buffer on every hardcoded weight.
I still think the relay side weights are fine, as the largest ones only happen inside the migration so the versions are "locked" together at that stage and when both chains are the same version we have no problem (emulated tests ensure this).
For the ones that are sent regularly we should ensure that the buffers are big enough to allow big jumps like this in the case that one chain upgrades before the other so we don't have to rely on co-ordinated releases.
@bkontur can you give some info about the errors reported for |
This comment was marked as outdated.
This comment was marked as outdated.
* Update hardcoded weights in coretime chain runtimes * Increase buffers
Running it with
A bit unfortunate, i will add an automatic fallback mode here like |
@ggwpez thank you! So here are ERROR-ed from description: Kusama
Polkadot
BridgeHubKusama
BridgeHubPolkadot
|
/merge |
Enabled Available commands
For more information see the documentation |
Head branch was modified
/merge |
Enabled Available commands
For more information see the documentation |
Head branch was modified
/merge |
Enabled Available commands
For more information see the documentation |
Head branch was modified
Trigger the v1.3.0 release with the following additional changes: - Bump `polkadot-runtime-parachains` version to get paritytech/polkadot-sdk#5369 in [63cb34d](63cb34d) and update tests in [e718c64](e718c64). - Filter calls to `interlace` on the Polkadot Coretime Chain until the relay implementation matures in [1126cf7](1126cf7). - Update all runtime versions to `1_003_000` in [08744df](08744df) TODO: - [x] Finalise changelog - [x] Wait for #433 - [x] Wait for #364 Closes #186 --------- Co-authored-by: Bastian Köcher <[email protected]> Co-authored-by: joe petrowski <[email protected]> Co-authored-by: fellowship-merge-bot[bot] <151052383+fellowship-merge-bot[bot]@users.noreply.github.com>
Closes: #436
(requested forcoretime-polkadot
andpolkadot
)TODO
polkadot-runtime
(in-progress / running)asset-hubs
(in-progress / running)The comparison of this branch with
main@ab0f42df90ae60a7e6192afce842eb0341b17efa
Note:
Change [%]
has threashold 5, so it show only if change is more than5%
or less than-5%
.Relay chains
Kusama
Polkadot
System parachains
AssetHubKusama
AssetHubPolkadot
BridgeHubKusama
BridgeHubPolkadot
CollectivesPolkadot
CoretimeKusama
CoretimePolkadot
PeopleKusama
PeoplePolkadot
GluttonKusama
EncointerKusama