# Paralel Initial Block Download PIBD TESTING

**URL:** <https://forum.grin.mw/t/paralel-initial-block-download-pibd-testing/10587>\
**Category:** Development and Technical Discussion\
**Created:** [June 15, 2023, 12:37pm UTC](https://forum.grin.mw/t/paralel-initial-block-download-pibd-testing/10587 "2023-06-15T12:37:17Z")\
**Posts on this page:** 1\
**Showing post:** 32

<div class="post-metadata">

**Author:** ![Anynomous](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.grin.mw/anynomous/32/2928_2.png) [@Anynomous](https://forum.grin.mw/u/Anynomous)\
**Post date:** [June 30, 2023, 8:00am UTC](https://forum.grin.mw/t/paralel-initial-block-download-pibd-testing/10587/32 "2023-06-30T08:00:10Z")

</div>

## Testing on Windows 10, four runs in total.

### I encountered a forced shutdown at step 4/7. Also some observations on speed in different steps, where it can be possible improved

**Step 1)** Downloading headers 0-2 MB/s, seed fluctuates. Sometimes drops to 0 kb/seconds (I monitored a graph of the internet speed). Based on disk usage over time, effective download speed is around 0.75 MB/s. Since I am connected to 24 peers and have at least 10 times the used download bandwidth, I suspect there is some unnecessary waiting before making new requests. Maybe check that new PMMR’s are already requested while old ones are being validated?  
**Step 2** , p2p protocol started, around 500 Kb according to wallet speed, with 24 peers  
According to wallet, step 2, chain state for sync is 1314(MB), took around 17:48:11-17:52 (so only 4 minutes for more than 1 GB around 6 MB/s based on disk space increase 🚀, and according to network monitor around 50 MB/s 🚀 Now that is the speed we also want in step 1.  
**Step 3)**, preparing for chain-sate validation, from 17:52-17:56, took 4 minutes XXX, CPU at 7.5%, so apparently a lot of calculations, done  
**Step 4)** Sync step 4/7: Validating chain state - range proofs:, 17:56 - 17:57, grin not responding, CPU, still one core full power working. 7.5 %, high power usage on and off, giving it some time, since it appears not hanging. Looking at logs, just a lot of verify\_kernel\_signatures. This all looks good except that it in the end results in a shutdown, probably because the normal p2p connection is not maintained/prioritized. Will run another test to see if this shutdown is a one time problem.

**Update:** 2nd run everything went smooth, around 1.5 hour for sync.  
**Update:** 3rd run everything went smooth, no crashes, sync in 1 hour and 15 minutes.  
**Update:** 4th run, enabled 16 threads instead of default 4. Sync time 1 hour and 37 minutes, so to many HTTP threads might even slow down syncing 🤔  
**Update:** 5th run, enabled 32 thread, 32 peers, Sync time was 1 hour and 18 minutes. More peers and more threads is not faster it appears, or at least it is saturated with lower numbers  
**Update:** 6th run, use default 8 peers, 4 threads.

> 20230629 18:02:15.353 ERROR grin\_p2p::peers - connected\_peers: failed to get peers lock  
> 20230629 18:02:15.353 ERROR grin\_p2p::peers - connected\_peers: failed to get peers lock  
> 20230629 18:02:15.353 DEBUG grin\_servers::common::adapters - send\_block\_request\_to\_peer: can’t send request to peer PeerAddr(107.174.186.153:3414), not connected  
> 20230629 18:02:15.353 ERROR grin\_p2p::peers - connected\_peers: failed to get peers lock  
> 20230629 18:02:15.353 DEBUG grin\_servers::common::adapters - send\_block\_request\_to\_peer: can’t send request to peer PeerAddr(192.3.254.163:3414), not connected  
> 20230629 18:02:15.353 ERROR grin\_p2p::peers - connected\_peers: failed to get peers lock  
> 20230629 18:02:15.353 DEBUG grin\_servers::common::adapters - send\_block\_request\_to\_peer: can’t send request to peer PeerAddr(45.77.150.172:3414), not connected  
> 20230629 18:02:15.353 ERROR grin\_p2p::peers - connected\_peers: failed to get peers lock  
> 20230629 18:02:15.353 DEBUG grin\_servers::common::adapters - send\_block\_request\_to\_peer: can’t send request to peer PeerAddr(121.43.174.18:3414), not connected  
> 20230629 18:02:15.353 DEBUG grin\_p2p::conn - Shutting down reader connection with 121.43.174.18:3414  
> 20230629 18:02:15.353 ERROR grin\_p2p::peers - connected\_peers: failed to get peers lock  
> 20230629 18:02:15.353 DEBUG grin\_servers::common::adapters - send\_block\_request\_to\_peer: can’t send request to peer PeerAddr(23.94.105.34:3414), not connected  
> 20230629 18:02:15.353 DEBUG grin\_p2p::conn - Shutting down reader connection with 23.94.105.34:3414  
> …More of the same, waiting then dropping peers, then a complete Shutdown!  
> 20230629 18:02:15.356 DEBUG grin\_p2p::peer - Waiting for peer PeerAddr(107.175.127.117:3414) to stop  
> 20230629 18:02:15.356 DEBUG grin\_p2p::conn - waiting for thread ThreadId(923) exit  
> 20230629 18:02:15.356 DEBUG grin\_p2p::conn - waiting for thread ThreadId(924) exit  
> 20230629 18:02:15.356 WARN grin\_servers:😁:server - Shutdown complete  
> RESTARTING NODE

After the restart, we are at step 7) this takes a bit (hanging at 99%, probably downloading the lats \<48h of blocks) done after 1 hour and 30 minutes of syncing, most time consumer by getting headers, more than an hour. Not bad, but I think in step 1 the speed can be made faster by making sure there are always requests made and new PMMR’s are stored in some buffer.

**Full log in DEBUG mode can be found here:**  
[https://github.com/Anynomouss/grin\_PIDB\_testing/blob/main/grin-server-run1%2C%201.5h.log2](https://github.com/Anynomouss/grin_PIDB_testing/blob/main/grin-server-run1%2C%201.5h.log2)

---

_[View the full topic](https://forum.grin.mw/t/paralel-initial-block-download-pibd-testing/10587)._