Full_node chia.full_node.full_node: WARNING Block validation time

Something new started, different from the typical >
Looking up qualities on U:\plot-k32-2021-09-01-21-59-xxxxx-plot took: 23.095717430114746. This should be below 5 seconds to minimize risk of losing
that I get occasionally (another mysterious problem).

Instead a single line like this one >

2021-10-08T09:23:24.594 full_node chia.full_node.full_node: WARNING Block validation time: 2.67 seconds, cost: 1458712997, percent full: 13.261%

I’m unclear on the difference between “Looking up qualities” and “Block validation time”, beside the fact the “Block validation time” WARNINGS just started appearing. Anyone else seeing these?

2 Likes

Have gotten this also today… maybe the 2.67 seconds is the warning trigger

WARNING Block validation time: 2.67 seconds, cost: 753779479, percent full: 6.853%

I see the same. Any update?

If your running chia of a hdd, move to a ssd. ( my advice ). I’m guessing your using ssd, or I think your times would be alot worse.

Upgrade hardware ( keybase support advice ).
To be fair, they didn’t say it was necessary, and the person asking was only getting just over 1 sec.
They did say keep an eye on it, but couldn’t give a figure of x seconds is a problem that needs fixing to stop loss of coin.

How much Ram did you have in your full node? Did the hardware upgrade work?

I have the same error. 5 NAS servers running as harvesters. Mac Mini M1 8 GB as the full node. Worried it doesn’t have enough memory.

I’m seeing this error message on my node, which is a Raspberry Pi 4 4GB. Running CLI only. The blockchain files are on their own SSD, everything else is running from a fast SD card (SanDisk Extreme).

From debug.log, e.g.
full_node chia.full_node.full_node: WARNING Block validation time: 2.69 seconds, pre_validation time: 0.71 seconds, cost: 1925053292, percent full: 17.5%

Has anyone found information on what each part of this warning means?

Background is I’m working though the log trying to eliminate or understand problems, because recently my node has become unreliable (stops syncing at regular intervals). Only a reboot of the OS will fix it (along with harvester machines too it seems). The error then isn’t reported immediately after a reboot, so will keep an eye out for it starting again, which I assume will happen. For those on Linux, I use tail and grep to monitor, although I expect there is a better way! For example:
tail -f ~/.chia/mainnet/log/debug.log | grep 'Block validation time'

The warning seems to have stopped on my node. Last time it was reported was 2021-12-03T23:46:41.137

Just seen another occurrence. Wondering if anyone had any luck deciphering this? Is it related to the full_node disconnect that occurs before it?

2021-12-08T15:43:12.759 full_node full_node_server        : WARNING  Cannot write to closing transport 13.40.13.242
2021-12-08T15:43:12.760 full_node full_node_server        : INFO     Connection closed: 13.40.13.242, node id: 501ddaf22c69893aa788207e8e409cab80d70012757a40f690ba048d7815d797
2021-12-08T15:43:12.761 full_node chia.full_node.full_node: INFO     peer disconnected {'host': '13.40.13.242', 'port': 8444}
2021-12-08T15:43:15.139 full_node chia.full_node.full_node: INFO     🌱 Updated peak to height 1250961, weight 2390326096, hh 7c2286e07982a78f6f8c379c1207ed488319e97eb3218f9ed872923ab41dcc21, forked at 1250960, rh: 6ff97da962ef050629cfd6b3e759a109069108f74e9a3626a88cbe6a1fb1faa2, total iters: 4753475911217, overflow: False, deficit: 6, difficulty: 2928, sub slot iters: 135266304, Generator size: 56758, Generator ref list size: 1
2021-12-08T15:43:15.148 full_node chia.full_node.mempool_manager: INFO     Size of mempool: 2 spends, cost: 14860814 minimum fee to get in: 0
2021-12-08T15:43:15.182 full_node chia.full_node.full_node: WARNING  Block validation time: 2.37 seconds, pre_validation time: 1.46 seconds, cost: 1553718676, percent full: 14.125%

I’m purely guessing, but think it’s more to do with the forked bit, which might have needed a block re org.

Thanks, is that an operation that would require a but of CPU grunt, which my RaspberryPi 4 might not quite be up to? Hence I get a warning that this activity took longer than expected.

I found this thread too, with similar lines of thinking.

My 8350 struggled with them, many ppl do though.
It seems generally ignored.