💬 hMsats commented on issue "bitcoind 29.0 much slower than 28.0 on my system: cause found":
(https://github.com/bitcoin/bitcoin/issues/32455#issuecomment-2925124875)
@sipa @andrewtoth

Maybe the solution is as trivial as increasing:

```
options.block_cache = leveldb::NewLRUCache(nCacheSize / 2);
options.write_buffer_size = nCacheSize / 4; // up to two write buffers may be held in memory simultaneously
```

in `src/dbwrapper.cpp`?

I have naively set (after putting back the LevelDB max file size increase to 32 MiB):

```
options.block_cache = leveldb::NewLRUCache(nCacheSize / 2 *16);
options.write_buffer_size = nCacheSize / 4 *16; // up to two write buffers
...

💬 sipa commented on issue "bitcoind 29.0 much slower than 28.0 on my system: cause found":
(https://github.com/bitcoin/bitcoin/issues/32455#issuecomment-2925132859)
@hMsats That's worth looking into or benchmarking, but I would be surprised if that has such a dramatic effect.

What filesystem are you using?

💬 hMsats commented on issue "bitcoind 29.0 much slower than 28.0 on my system: cause found":
(https://github.com/bitcoin/bitcoin/issues/32455#issuecomment-2925136624)
@sipa

`/dev/sdb1 ext4 1.8T 935G 805G 54% /media/ssd`

it contains .bitcoin and the CLN and Fulcrum data

💬 andrewtoth commented on issue "bitcoind 29.0 much slower than 28.0 on my system: cause found":
(https://github.com/bitcoin/bitcoin/issues/32455#issuecomment-2925137848)
> Fulcrum would retry every 5 seconds which would fill up my rpcworkqueue quickly

v29 also increased `rpcworkqueue` to 64 by default, so that line is redundant. By keeping `rpcthreads` at 4 you are limiting the number of concurrent requests to 4, while default can now service 16 at a time. That would also help keep the work queue lower since requests in the queue can be processed faster.

💬 hMsats commented on issue "bitcoind 29.0 much slower than 28.0 on my system: cause found":
(https://github.com/bitcoin/bitcoin/issues/32455#issuecomment-2925138046)
The following are the `Verifying last 3 blocks at level 3` times on the last 3 runs, and my new run

```
debug.log_Fri_May_30_05:58:19_AM_CEST_2025:2025-05-29T11:26:33Z Verification progress: 0%
debug.log_Fri_May_30_05:58:19_AM_CEST_2025-2025-05-29T11:26:38Z Verification progress: 33%
debug.log_Fri_May_30_05:58:19_AM_CEST_2025-2025-05-29T11:26:53Z Verification progress: 66%
debug.log_Fri_May_30_05:58:19_AM_CEST_2025-2025-05-29T11:26:58Z Verification progress: 99%
25 s
--
debug.log_Fri_May_30_09:
...

💬 hMsats commented on issue "bitcoind 29.0 much slower than 28.0 on my system: cause found":
(https://github.com/bitcoin/bitcoin/issues/32455#issuecomment-2925140605)
@andrewtoth but `nproc` command gives the answer 4. Is it still worth will to set `rpcthreads` to 16?

💬 andrewtoth commented on issue "bitcoind 29.0 much slower than 28.0 on my system: cause found":
(https://github.com/bitcoin/bitcoin/issues/32455#issuecomment-2925144203)
Yes, since the requests are io bound they will mostly be waiting concurrently and not using much CPU.

💬 sean-k1 commented on pull request "rpc: Support v3 raw transactions creation":
(https://github.com/bitcoin/bitcoin/pull/31936#issuecomment-2925148327)
@achow101 @maflcko
we fixed the lint error.
There seems to be a lot of discussion, let me know when it's clear.

💬 hMsats commented on issue "bitcoind 29.0 much slower than 28.0 on my system: cause found":
(https://github.com/bitcoin/bitcoin/issues/32455#issuecomment-2925149364)
OK, thanks a lot. I will remove it sooner or later!

💬 sipa commented on pull request "Replace cluster linearization algorithm with SFL":
(https://github.com/bitcoin/bitcoin/pull/32545#issuecomment-2925180422)
@instagibbs @ismaelsadeeq @gmaxwell FWIW, I didn't include apples-to-apples comparison because the large-scale comparison [benchmarks](https://delvingbitcoin.org/t/how-to-linearize-your-cluster/303/73) I did (especially, [this one](https://delvingbitcoin.org/uploads/default/original/2X/2/22ad16f71db37fcb8cadb8a8f73c4acfd3def203.png)) were just overwhelmingly in favor of SFL over the existing one. The benchmarks were mostly done to decide between SFL and another replacement algorithm, GGT, but se
...

💬 ismaelsadeeq commented on issue "test: `feature_fee_estimation` failure after duplicate coinbase tx weight reservation fix [AssertionError: Estimated fee (0.00923427) out of range]":
(https://github.com/bitcoin/bitcoin/issues/32461#issuecomment-2925282272)
> Also, it's quite strange that the test started failing on this commit: [https://github.com/bitcoin/bitcoin/commit/6b165f5906fc53bd10bedff85a6ef26e0aabdc5c](https://github.com/bitcoin/bitcoin/commit/6b165f5906fc53bd10bedff85a6ef26e0aabdc5c)
> I haven't looked into that yet.

I’ve debugged the issue and discovered why this seed only fails on commit 6b165f5906fc53bd10bedff85a6ef26e0aabdc5c

This is because, prior to that commit, we reserved only 8000 WU only when using the default `-blockmaxweigh
...

💬 hMsats commented on issue "bitcoind 29.0 much slower than 28.0 on my system: cause found":
(https://github.com/bitcoin/bitcoin/issues/32455#issuecomment-2925284510)
Increasing `options.block_cache` and `options.write_buffer_size` didn't (really) help. Back to removing the LevelDB max file size increase.

💬 pinheadmz commented on pull request "[28.x] Backport #31407":
(https://github.com/bitcoin/bitcoin/pull/32563#issuecomment-2925310556)
Should I try to build and sign again? Recent just looks like a repository change.

💬 fanquake commented on pull request "[28.x] Backport #31407":
(https://github.com/bitcoin/bitcoin/pull/32563#issuecomment-2925315157)
Yea, just a rebase on the Guix repo change. If you don't mind building again, that'd be great. Can debug.

📝 ismaelsadeeq opened a pull request: "init: deprecate `-blockmaxweight` startup option"
(https://github.com/bitcoin/bitcoin/pull/32654)
This PR deprecate `-blockmaxweight` option marked it for removal in the future as discussion in https://github.com/bitcoin/bitcoin/pull/31384#discussion_r1945280589

The plan is to deprecate it in v30 and remove it in v31.

Miners can lower the block weight using `-blockreservedweight` option.

💬 l0rinc commented on issue "bitcoind 29.0 much slower than 28.0 on my system: cause found":
(https://github.com/bitcoin/bitcoin/issues/32455#issuecomment-2925382555)
> shouldn't options.block_cache and options.write_buffer_size be increased?

I have experimented a lot with these and they all just slowed down IBD for me. Definitely let us know if it's different on your system.

Compaction could theoretically be a problem, but my understanding is that it would just mean that a few spikes are larger, most other processing should be significantly faster. Is this your only complain? On average this made IBD and block processing in general ~30% faster - but there'
...

💬 tnndbtc commented on pull request "fee estimate test: fix #31944 by handling a legitimate scenario that …":
(https://github.com/bitcoin/bitcoin/pull/32615#discussion_r2118030536)
@ismaelsadeeq Agree. So, I took a list of good fees that will guarantee to pass the check of fees and smart fees and hard code them for the test. This way the randomness is gone and it's deterministic now.

🤔 polespinasa reviewed a pull request: "init: deprecate `-blockmaxweight` startup option"
(https://github.com/bitcoin/bitcoin/pull/32654#pullrequestreview-2884321525)
cACK

Needs release note

💬 polespinasa commented on pull request "init: deprecate `-blockmaxweight` startup option":
(https://github.com/bitcoin/bitcoin/pull/32654#discussion_r2118049736)
If the plan is to remove on v31 maybe specifying it is a good idea.
See https://github.com/bitcoin/bitcoin/blob/4b1d48a6866b24f0ed027334c6de642fc848d083/src/wallet/wallet.cpp#L3006-L3007

💬 pinheadmz commented on pull request "[28.x] Backport #31407":
(https://github.com/bitcoin/bitcoin/pull/32563#issuecomment-2925427970)
same issue, `RuntimeError: File size too large, try using force_zip64`