RockPro64 sync instability issues

[dawiepoolman]

Hi guys

Have any of you experienced the same instability issues the I am having syncing monero like I did here: https://github.com/monero-project/monero/issues/8473

Are there any potential config options one can consider to 'make it sync slower' eg --maxconcurrency=1 or block-sync-size=1? I have tried everything I can think off which makes me believe it has to be a hardware issue.

[dawiepoolman]

@shermand100 I would recommend looking into how we resolved the rockpro64 sync issue and maybe make it part of the script/readme for the guys running rockpro64 boards to circumvent the corruption vulnerability

[shermand100]

A lengthy read but thanks for sharing. I'm in the same boat as HYC in that I've not had any issues at all with my RockPro64 and have sync'd from scratch twice.

Was your conclusion that by enabling the governor you reduced memory issues?

From your first comment here I've always been against reducing or altering from the default Monero sync behavior. At absolute most 250MB of block data it parsed at a time: https://monerodocs.org/interacting/monerod-reference/#performance

--db-sync-mode | Specify sync option, using format:[safe\|fast\|fastest]:[sync\|async]:[[blocks]\|[bytes]]The default is fast:async:250000000bytes.The fast:async:* can corrupt blockchain database in case of a system crash. It should not corrupt if just monerod crashes. If you are concerned with system crashes use safe:sync. -- | --

Which only really kicks in after the checkpoints, the most recent of which: https://github.com/monero-project/monero/blob/master/src/checkpoints/checkpoints.cpp#L176

ADD_CHECKPOINT2(1958000, "98a5d6e51afdf3146e0eefb10a66e8648d8d4d5c2742be8835e976ba217c9bb2", "0x79dd46d2a0971a");
ADD_CHECKPOINT2(2046000, "5e867f0b8baefed9244a681df97fc885d8ab36c3dfcd24c7a3abf3b8ac8b8314", "0x9cb8b6ff2978c6");
ADD_CHECKPOINT2(2092500, "c4e00820c9c7989b49153d5e90ae095a18a11d990e82fcc3be54e6ed785472b5", "0xb4e585a31369cb");
ADD_CHECKPOINT2(2182500, "0d22b5f81982eff21d094af9e821dc2007e6342069e3b1a37b15d97646353124", "0xead4a874083492");
ADD_CHECKPOINT2(2661600, "41c9060e8426012238e8a26da26fcb90797436896cc70886a894c2c560bcccf2", "0x2e0d87526ff161f");

Don't get me wrong, I don't see it as feasible anymore to use weak hardware to sync from scratch (although the determined are still out there - someone recently did it with a 32bit Odroid HC1 with HDD with PiNodeXMR - ) But the RockPro64 is not a weak board.

Are there any further suggestions? Has stability been an issue since? I guess it's early days for that device.

[dawiepoolman]

Yes, the fix was to enable the powersave governor.
I only intent to create awareness of what looks like a hardware production issue that could potentially affect other rockpro64 boards. It is likely a small percentage of the boards but it looks like there were detected issues with ddrm clock speeds as pointed out in that long monero issue thread.

At least we have a workaround in case someone else picks up a vulnerable rockpro64 board in this community.

Thanks for the info on the 250Mb block data. I have not noticed that size limit before but looks like another conservative safety catch that the devs considered already.

Good, I am closing this for archive. Thanks again for maintaining this project.

[shermand100]

Note added to Hardware Wiki for the RockPro64