Willian Mitsuda

> [@wmitsuda](https://github.com/wmitsuda) `CommitmentVals 125.140G` - what is `integration print_stages` stepsInDb? (I guess need use in code `rawdbhelpers.IdxStepsCountV3(applyTx)` because `integration` will use wrong step size) I don’t have scenario 3 chaindata...

so, if nobody has an objection, I'm going to do round 3 of this experiment in the next 3 days by: - Repeating the scenarios of round 2, 12 hours...

> > * what is the value of `s.CurrentSyncCycle.IsInitialCycle` if we run with `--loop.sync.block.limit=16` > * `quickPruneTimeout := 250 * time.Millisecond` let's add env variable to increase it > *...

> and: > > * rawdbhelpers.IdxStepsCountV3() add to collected data?

no, I'm not setting anything, running on my own machine

FYI, actually, for round 3 I'm going to first run scenario 1 (no step size changes) twice, 1 using the current commit from MIlen (~2 months ago), then move to...

update 01/12/25: we are syncing a new snapshotter for bloatnet based on commit `07e7965c48254d4378316cdc380ff27d36364d6e` from `performance` branch. No changes on step size were made, goal here is to reach the...

update 08/12: at block 22.89M using `--sync.block.loop.limit` == 128. Will try to double it to 256 and observe the effects.

update 10/12: back to block 22.7M bc deleted chaindata 2 days ago; trying `--sync.block.loop.limit == 1024` in order to observe effects on monitoring.

it looks like my hypothesis was correct, bigger `--sync.block.loop.limit` is actually better. going from 256 -> 1024 increased blocks by 4x, but time taken to exec+commitment increased by only ~2x....