pull down to refresh

300 sats \ 9 replies \ @optimism 2 Nov \ on: Stacker Saloon
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.
write
preview
100 sats \ 6 replies \ @0xbitcoiner 2 Nov
1 core (quad-core ARM Cortex-A72 CPU) performance?
reply
218 sats \ 4 replies \ @optimism 2 Nov
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
100 sats \ 1 reply \ @0xbitcoiner 2 Nov
inscriptions related?
reply
33 sats \ 0 replies \ @optimism 2 Nov
Perhaps. P2SH and p2wpkh consolidation txs are slow af too.
reply
100 sats \ 1 reply \ @SimpleStacker 2 Nov
Seems consistent with my experience that around block 700k sync slowed to a crawl
reply
0 sats \ 0 replies \ @optimism 2 Nov
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
66 sats \ 0 replies \ @optimism 2 Nov
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
135 sats \ 1 reply \ @SimpleStacker 2 Nov
This is amazing work. Have you thought about publishing all your findings into a single article?
reply
30 sats \ 0 replies \ @optimism 2 Nov
When I have a fix, sure.
reply