-
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
Coretime Chain: mitigate behaviour with many assignments on one core #434
Coretime Chain: mitigate behaviour with many assignments on one core #434
Conversation
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.
When the relay chain accepts multiple assignments, we should make the XCM call generation more flexible and not just assume that 28
the magic number will always work. Thus, I see no need to keep the chunking right now.
Co-authored-by: Bastian Köcher <[email protected]>
/merge |
Enabled Available commands
For more information see the documentation |
437ebb3
into
polkadot-fellows:main
) Fixed in Polkadot and Kusama in polkadot-fellows/runtimes#434 and this PR just adds to testnets. We can handle a maximum of 28 assignments inside one XCM, while it's possible to have 80 (if a region is interlaced 79 times). This can be chunked on the coretime chain side but currently the scheduler on the relay makes assumptions that means we can't send more than one chunk for a given core. This just truncates the additional assignments until we can extend the relay to support this. This means that the first 27 assignments are taken, the final 28th is used to pad with idle to complete the mask (the relay also assumes that every schedule is complete). Any other assignments are dropped. --------- Co-authored-by: Kian Paimani <[email protected]>
We can handle a maximum of 28 assignments inside one XCM, while it's possible to have 80 (if a region is interlaced 79 times).
This can be chunked on the coretime chain side but currently the scheduler on the relay makes assumptions that means we can't send more than one chunk for a given core.
I've made a mitigation here that requires no sdk release, but it just truncates the additional assignments until we can extend the relay to support this. This means that the first 27 assignments are taken, the final 28th is used to pad with idle to complete the mask (the relay also assumes that every schedule is complete). Any other assignments are dropped.