It starts slowing down before that (around block 790k), but it gets real nasty after it (840k+ on 29.x). I'm not 100% convinced that it is only secp - am natively compiling bench right now for 26, 27, 28, 29 and 30 - see if I can spot a regression

txin verification would indeed make me think that it’s the retrieval of UTXO cache misses. I’ve been hearing that the disk interface of Raspberry Pis is pretty slow, so the disk itself might not be the issue, but rather the speed at which the Pi talks to the disk?

> the main issue are secp256k1 functions

Is this during the full validation part of IBD after passing the assumevalid block? Otherwise, I wouldn’t expect many calls to secp.

Murch

, except your point #2. I had tested with the "raspibolt" recommendation of 2GB. The problem on rpi4 is txin verification:

- Verify 9995 txins: 34716.35ms (3.473ms/txin) [51906.08s (65.15ms/blk)]

but it's unlikely to be the disk or the cache! I cannot reproduce on an Odroid M2 with exactly the same disk (as in I plugged it out of the rpi4 and into the odroid) and cache settings.

I've seen some traces from others where the main issue are 

 functions and I remember some changes have been made to replace hand coded ASM with "clang is better". I'm trying to find a few days to get into the weeds on this one and just create a bunch bench cases to see if I can pinpoint it without needing to pprof a live mainnet process. Worst case I'll build a regtest script and do it that way. Anything to not have to profile a mainnet bitcoind haha.

bitcoin_beginners

lightning

How to set up a Raspberry Pi node

06bc1a977d

Hey Murch,

All this is taken care of in my [repro](https://stacker.news/items/1262053/r/optimism?commentId=1262279), except your point #2. I had tested with the "raspibolt" recommendation of 2GB. The problem on rpi4 is txin verification:

```
- Verify 9995 txins: 34716.35ms (3.473ms/txin) [51906.08s (65.15ms/blk)]
```

but it's unlikely to be the disk or the cache! I cannot reproduce on an Odroid M2 with exactly the same disk (as in I plugged it out of the rpi4 and into the odroid) and cache settings.

I've seen some traces from others where the main issue are `secp256k1` functions and I remember some changes have been made to replace hand coded ASM with "clang is better". I'm trying to find a few days to get into the weeds on this one and just create a bunch bench cases to see if I can pinpoint it without needing to pprof a live mainnet process. Worst case I'll build a regtest script and do it that way. Anything to not have to profile a mainnet bitcoind haha.