re-calibrate limit based on mainnet data#21995
re-calibrate limit based on mainnet data#21995tao-stones merged 2 commits intosolana-labs:masterfrom
Conversation
|
The adjustment is based on mainnet data collected since 1.8.10. The best way to check out if it strikes a better balance between block's fullness and parallelism is perhaps to test it in testnet, with |
|
@taozhu-chicago the metrics aren't loading for me, do you have another link or screenshot? It'd also be nice to have a comment explaining where each of these constants came from |
| pub const MAX_BLOCK_REPLAY_TIME_US: u64 = 400_000; | ||
| /// number of concurrent processes, | ||
| pub const MAX_CONCURRENCY: u64 = 10; | ||
| pub const MAX_CONCURRENCY: u64 = 4; |
There was a problem hiding this comment.
What does this mean? Max Block = 4* max compute per account?
There was a problem hiding this comment.
ideally, banking threads run concurrently without being blocked by each other (on accounts). MAX_CONCURRENCY represents number of threads under such condition. Therefore the block_max = account_max * MAX_CONCURRENCY
runtime/src/block_cost_limits.rs
Outdated
| (secp256k1_program::id(), COMPUTE_UNIT_TO_US_RATIO * 4), | ||
| (system_program::id(), COMPUTE_UNIT_TO_US_RATIO * 10), | ||
| (solana_vote_program::id(), COMPUTE_UNIT_TO_US_RATIO * 70), | ||
| (secp256k1_program::id(), COMPUTE_UNIT_TO_US_RATIO * 2), |
There was a problem hiding this comment.
what timing is this based on? Because the actual work of the secp256k1 program is not in the instruction execution part, it's executed in banking stage before it hands it to the message processor.
There was a problem hiding this comment.
The 2us is collected from per-program-timing metrics for secp256K1 (the dashboard linked in the issue #21917). So its actual number should come from banking stage?
There was a problem hiding this comment.
yea, the message processor part of it is like a no-op. We can cost it similar to a regular signature verify I think.
There was a problem hiding this comment.
Cool, changed it
Codecov Report
@@ Coverage Diff @@
## master #21995 +/- ##
=========================================
- Coverage 81.1% 81.1% -0.1%
=========================================
Files 523 523
Lines 146370 146370
=========================================
- Hits 118747 118735 -12
- Misses 27623 27635 +12 |
tao-stones
force-pushed
the
recalibrate-cost-limit
branch
from
a312a6f to
bf24909
Compare
4 participants
Problem
Adjust cost limit to better reflect mainnet data collected via dashboard
Summary of Changes
numbers collected
Fixes #
#21917