We want to get some real world numbers by stress testing the parachain block size, PoV size and 2s execution with async backing and elastic scaling.
Ideally, the number of gluttons should be increased over time as much as possible given that we have so many spare cores on Kusama. If we find the load is too much and the network degrades we can easily kill some of them and stop the bleeding.
We are interested in the following metrics:
Do we see these candidates disputes (and maybe others due to load)
finality lag
network cpu load, both libp2p and litep2p
availability metrics
erasure coding timings
Parachain block times
Q: Could we use testnet-manager to manage these parachains ? cc @PierreBesson
We want to get some real world numbers by stress testing the parachain block size, PoV size and 2s execution with async backing and elastic scaling.
Ideally, the number of gluttons should be increased over time as much as possible given that we have so many spare cores on Kusama. If we find the load is too much and the network degrades we can easily kill some of them and stop the bleeding.
We are interested in the following metrics:
Q: Could we use testnet-manager to manage these parachains ? cc @PierreBesson
LE: This should be part of testing 10MB PoVs.