Block import should be at least 100bps

[gnunicorn]

investigating #448 we are seeing continuous 100% CPU (caused by one thread per one core) if we run --validator --chain dev --key Alice, even without any other nodes connected. We are not seeing this, if the node is not the proposer. However if we link up the proposing node with another node, we are also seeing a continuous 100% CPU usage of two threads on that second node. This suggests we are looping without necessity in the importing thread.

[jordy25519]

I can't repro this with a lone proposer node on latest master.

When syncing I observe CPU usage at 100% on the import queue thread but I guess this is the expected behaviour as blocks are being on boarded. CPU usage drops off once fully synced.

[gnunicorn]

@Holygits are you running node in the --dev configuration? Because in there you'd be the only one proposing blocks and do that every 4seconds, means you never "stop syncing". Here with a Dell XPS13 2017, this takes longer than 4seconds itself, thus creating a continuous 100% CPU usage. It shouldn't take this long for empty blocks to be imported (it certainly didn't in the past).

[jordy25519]

I've run this command: substrate --validator --chain dev --key Alice and can see fluctuations from 0-20% CPU at the most.
I'm running on a Macbook Pro w 3.1 GHz Intel Core i5

Here with a Dell XPS13 2017, this takes longer than 4seconds itself, thus creating a continuous 100% CPU usage

Ah. So this problem occurs when the block import rate is slower than block proposal rate.
Seems like reproducing this maybe hardware specific

[jordy25519]

Should've mentioned I'm running a release build.
I've just tried running the same command above with a debug build and it periodically shoots upto ~98% CPU usage.

[xlc]

Yeah debug build block importing is not usable

2018-12-06 23:27:47 Syncing  0.2 bps, target=#19164 (2 peers), best: #16508 (0x2fe2…b9a4)
2018-12-06 23:27:52 Syncing  0.4 bps, target=#19164 (2 peers), best: #16510 (0x0115…2964)
2018-12-06 23:27:57 Syncing  0.4 bps, target=#19164 (2 peers), best: #16512 (0x05b3…b869)

Release build is much faster (still not fast enough though)

2018-12-06 23:33:49 Syncing  6.8 bps, target=#19204 (2 peers), best: #16560 (0x0027…a45b)
2018-12-06 23:33:54 Syncing  6.8 bps, target=#19204 (2 peers), best: #16594 (0x57d5…765d)
2018-12-06 23:33:59 Syncing  6.6 bps, target=#19205 (2 peers), best: #16627 (0xbafa…cb4b)```

[bkchr]

This function is the dominating function in my traces when syncing. I'm currently trying to improve the performance.
By switching the hash function, I'm already seeing an improvement, from 20-26bps to 40bps.

[gavofyork]

Currently seeing a steady 170bps during sync.