XCMP weight metering: account for the MQ page position

[serban300]

Related to #8308
Follow-up for #8021

[serban300]

/cmd bench --pallet cumulus_pallet_xcmp_queue

[github-actions]

Command "bench --pallet cumulus_pallet_xcmp_queue" has started 🚀 See logs here

[github-actions]

Command "bench --pallet cumulus_pallet_xcmp_queue" has failed ❌! See logs here

[serban300]

/cmd bench --pallet cumulus_pallet_xcmp_queue

[github-actions]

Command "bench --pallet cumulus_pallet_xcmp_queue" has started 🚀 See logs here

[github-actions]

Command "bench --pallet cumulus_pallet_xcmp_queue" has failed ❌! See logs here

[bkontur]

Unrelated question:
Can we now determine the exact/approx number of XCMP queue throughput for a parachain based on the runtime’s queue configuration?

For example, if we consider some common/average XCM message and the actual AssetHubWestend runtime configuration for queues - can we approximately calculate the maximum number of such messages that can be processed per block (assuming no other extrinsics are included)? In other words, what's the maximum number of these XCM messages AHW can process/enqueue in a single block?

If this is feasible, maybe we could also introduce a basic sanity/integrity test to get a sense of the current throughput numbers.

cc: @sandreim had this question yesterday

[serban300]

Unrelated question: Can we now determine the exact/approx number of XCMP queue throughput for a parachain based on the runtime’s queue configuration?

For example, if we consider some common/average XCM message and the actual AssetHubWestend runtime configuration for queues - can we approximately calculate the maximum number of such messages that can be processed per block (assuming no other extrinsics are included)? In other words, what's the maximum number of these XCM messages AHW can process/enqueue in a single block?

If this is feasible, maybe we could also introduce a basic sanity/integrity test to get a sense of the current throughput numbers.

cc: @sandreim had this question yesterday

@bkontur You mean the number of inbound messages that can be enqueued per block by the XCMP pallet ?

If so, yes. The block ref time assigned for this operation is 0.125s, no matter how many other extrinsics are included :

polkadot-sdk/cumulus/parachains/runtimes/assets/asset-hub-westend/src/lib.rs

Line 778 in ff5c67c

pub const ReservedXcmpWeight: Weight = MAXIMUM_BLOCK_WEIGHT.saturating_div(4);

And we can use the computed weights in order to see how many messages can be enqueued using 0.125s. We need some assumptions related to the average message size, the number of new pages, etc. Considering the current weights we can enqueue about 20k small messages in a block

[sandreim]

Thanks @serban300. What does "small message" mean in bytes ?

[serban300]

Thanks @serban300. What does "small message" mean in bytes ?

@sandreim "small messages" means 3 bytes in this case, but the weight doesn't increase by a lot with the number of bytes. If you have a certain message size in mind, I can redo the computations.