pull down to refresh

This is what txin verification performance looks like on an RPi4 (charted for blocks 790k-815k)
There seems to be some relation between the mean size of txs in a block (in terms of inputs) and the performance of IBD. Moving on to running benches.
This is amazing work. Have you thought about publishing all your findings into a single article?
reply
When I have a fix, sure.
reply
1 core (quad-core ARM Cortex-A72 CPU) performance?
reply
Also, this reproduction of "after block 800k it goes insane" is why I'm looking at this in the first place after @SimpleStacker reported it on the raspiblitz GH:
Note that y-axis is log10.
reply
Seems consistent with my experience that around block 700k sync slowed to a crawl
reply
Before 790, it's mostly blocks with consolidation txs that slow it down to > 1ms per utxo at times. After 790 it's almost every block, but this is the worst performing one I have: https://mempool.space/block/00000000000000000001ee48d567e68a768cc36cb7b47bd6ae1dc10c931c13d5 at 30ms per utxo, 10900 utxo in the block, all p2sh
reply
inscriptions related?
reply
Perhaps. P2SH and p2wpkh consolidation txs are slow af too.
reply
Yes. It's cpu bound through the b-msghand thread (basically the bulk of net_processing) also, this is still under assumevalid's range.
reply