-reindex-chainstate frequent extended pauses

[callmejoe]

i've been running a -reindex-chainstate the last several days on my raspberry pi.  i've noticed it stops updating for 40 minutes at a time frequently.  from looking at the debug.log i see socket timeouts at 2300-2400s which is about 40 minutes.  and the timestamp from 2 consecutive block updates are 40 minutes apart.  

am i reading this right? and any way to shorten the timeout period?

Code:

2019-05-18T02:52:29Z UpdateTip: new best=0000000000000000012c181fce4f2ec065c3eb773cccc5d72251c2595a038fe9 height=479717 version=0x20000012 log2_work=86.904758 tx=244935503 date='2017-08-08T20:58:30Z' progress=0.624972 cache=726.0MiB(6524861txo)
2019-05-18T03:31:05Z UpdateTip: new best=000000000000000000221493a90a785c16e72ccd48733c4e08231a50ae331480 height=479718 version=0x20000002 log2_work=86.904794 tx=244937679 date='2017-08-08T21:11:39Z' progress=0.624968 cache=28.8MiB(0txo)
2019-05-18T03:31:06Z Potential stale tip detected, will try using extra outbound peer (last tip update: 2364 seconds ago)
2019-05-18T03:31:07Z socket sending timeout: 2378s
2019-05-18T03:31:07Z ping timeout: 3207.307425s
2019-05-18T03:31:07Z ping timeout: 2862.919345s
2019-05-18T03:31:07Z socket sending timeout: 2450s
2019-05-18T03:31:07Z socket sending timeout: 2472s
2019-05-18T03:31:07Z socket sending timeout: 2377s
2019-05-18T03:31:07Z socket sending timeout: 2365s
2019-05-18T03:31:07Z socket send error Broken pipe (32)
2019-05-18T03:31:10Z New outbound peer connected: version: 70014, blocks=576547, peer=3828
2019-05-18T03:31:10Z New outbound peer connected: version: 70015, blocks=576547, peer=3843
2019-05-18T03:31:11Z New outbound peer connected: version: 70015, blocks=576547, peer=3858
2019-05-18T03:31:11Z socket send error Broken pipe (32)
2019-05-18T03:31:12Z New outbound peer connected: version: 70015, blocks=576547, peer=3876
2019-05-18T03:31:13Z New outbound peer connected: version: 70015, blocks=576547, peer=3892
2019-05-18T03:31:39Z UpdateTip: new best=0000000000000000013e89971ec0f1bdd43cc31aeb82a2491149340f76aaa07b height=479719 version=0x20000002 log2_work=86.904831 tx=244939945 date='2017-08-08T21:22:13Z' progress=0.624974 cache=29.8MiB(9308txo)
2019-05-18T03:32:14Z UpdateTip: new best=0000000000000000013236ef38095c2c129f839ea7283a65640fa5fdd859e282 height=479720 version=0x20000012 log2_work=86.904868 tx=244942106 date='2017-08-08T21:36:51Z' progress=0.624979 cache=30.7MiB(17540txo)
2019-05-18T03:32:31Z UpdateTip: new best=000000000000000000a64e454307e39e6ec4a9a5730e0f906819d1508e1011a8 height=479721 version=0x20000002 log2_work=86.904905 tx=244944571 date='2017-08-08T21:55:37Z' progress=0.624986 cache=31.5MiB(24592txo)

[1714236492]

1714236492

[DaveF]

Short version. No.

Remember, it's a RPi, it's slow with not a lot of ram and horrible I/O speeds.
If this is the same machine from your last post you have everything running on an SD card, which is going to make it even slower.

-Dave

[callmejoe]

Short version. No.

Remember, it's a RPi, it's slow with not a lot of ram and horrible I/O speeds.
If this is the same machine from your last post you have everything running on an SD card, which is going to make it even slower.

-Dave

yes same machine.   i am going to try to be patient with this.  i just was hoping i can stop these 40 minute "work stoppages" at a time.

[ABCbits]

Just be patient, RPi is barebone PC and there's nothing much you could do.

But if you're not patient, there are few options :
1. Tweak dbcache, maxsigcachesize & rpcthreads value on start-up parameter or bitcoin.conf file. Not recommended because you could encounter "Out of memory" problem
2. Overclock CPU & RAM. Also not recommended for obvious reason.
3. Store whole Bitcoin folder on SSD. But, AFAIK there's major bottleneck from CPU/RAM and IMO you won't see any significant performance difference.

[callmejoe]

ok im at block 536,258...in the home stretch....

the whole time this has been reindexing the process used 1-2 cores of 4 and maybe got up to 25% of CPU.  now it seems suddenly all 4 cores are being used at 95%+ and has really sped up going through the blocks.

any reason it didnt utilize all the processing power available from the beginning?