Closed dawiepoolman closed 1 year ago
@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
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]:[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.
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.
Note added to Hardware Wiki for the RockPro64
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.