Hi!
(I'm new, might be doing beginner mistakes.)
Using "monero-gui-win-x64-v0.18.4.7.zip" release.
I currently have a working monerod with full blockchain, with an xmrig successfully mining using it.
Intel i5-13600K processor (6 P cores hyperthreading to 12 threads, 8 E cores, totaling in 20 threads), Windows 11.
Monerod and the blockchain are on an m.2 nvme ssd (ntfs) inside the PC currently, but several of the tests below where done while the blockhain was on a (decently fast) pendrive's btrfs partition with a btrfs driver installed on win11. Still, the same crashing behavior continued after I moved the blockchain to the m.2 ssd.
Same crashing happened with windows real time protection turned off, and I've also added the folder and monerod specifically as exclusions.
I start monerod with monerod --config-file .\config\monerod.conf from a cmd.
As soon as I start mining with 10 threads, it crashes (closes) after a few seconds. I can't see anything relevant in bitmonero.log, even at log level 2. For some reason, it doesn't crash on log level 3 and 4, or i just didn't wait enough or idk (but obviously I don't want to actively run long-term on that log level). A few times It also didn't crash with log level 0 and 2 (haven't tried log 1 much). I have a log saved with log level 2 that crashed and one that didn't, but I don't see any glaring entries that indicate why one would have crashed. It does crash more often than not.
I started to experiment a bit more after that. Log level 0.
I set the affinity to 0xff500 with start /affinity 0xff500 monerod --config-file .\config\monerod.conf (meaning one thread from two separate P cores, and all 8 E cores are availabe).
2 threads seem to work fine, and two of the P cores work on 100%.
with 3 threads, mostly 2 of the P cores are on 100%, and some of the E cores are running various amounts, none 100%. I've had it crash once with 3 threads after i sent the stop_mining command, but a few other times it worked fine.
4 threads were similar and similar perf to 3 threads, and stop_mining crashed it again.
I also notice that sometimes the cmd window starts visually different, in a smaller size/font, idk why.
And rarely, it started up noticeable slower than most other times, in fact i opted to close those and restart monerod.
Next two times, starting the 4 threads crashed it after a few seconds.
Starting it with 0xfff affinity to exclude the E cores and keep only the P cores, starting to mine on 12 threads also crashes it.
4 threads seems to work. 6 thread worked too. starting 7 threads crashed it.
With 0x555 affinity to only include one of the threads of each P core, starting to mine with 6 threads crashes it after a few seconds. 4 threads crashed it like that too. 2 threads seems to work fine. 3 crashed it on start.
With 0xff000 (so only E cores), 1, 2, 3, and 4 threads started and stopped properly once, but then starting 5 threads crashed, and after that starting 4 threads crashed it too.
xmrig mines just fine with all 20 cpu cores/threads if needed, or with less as I configure.
I'm personally fine with xmrig mining at this point, but wanted to report the issue.
Hi!
(I'm new, might be doing beginner mistakes.)
Using "monero-gui-win-x64-v0.18.4.7.zip" release.
I currently have a working monerod with full blockchain, with an xmrig successfully mining using it.
Intel i5-13600K processor (6 P cores hyperthreading to 12 threads, 8 E cores, totaling in 20 threads), Windows 11.
Monerod and the blockchain are on an m.2 nvme ssd (ntfs) inside the PC currently, but several of the tests below where done while the blockhain was on a (decently fast) pendrive's btrfs partition with a btrfs driver installed on win11. Still, the same crashing behavior continued after I moved the blockchain to the m.2 ssd.
Same crashing happened with windows real time protection turned off, and I've also added the folder and monerod specifically as exclusions.
I start monerod with
monerod --config-file .\config\monerod.conffrom a cmd.As soon as I start mining with 10 threads, it crashes (closes) after a few seconds. I can't see anything relevant in bitmonero.log, even at log level 2. For some reason, it doesn't crash on log level 3 and 4, or i just didn't wait enough or idk (but obviously I don't want to actively run long-term on that log level). A few times It also didn't crash with log level 0 and 2 (haven't tried log 1 much). I have a log saved with log level 2 that crashed and one that didn't, but I don't see any glaring entries that indicate why one would have crashed. It does crash more often than not.
I started to experiment a bit more after that. Log level 0.
I set the affinity to 0xff500 with
start /affinity 0xff500 monerod --config-file .\config\monerod.conf(meaning one thread from two separate P cores, and all 8 E cores are availabe).2 threads seem to work fine, and two of the P cores work on 100%.
with 3 threads, mostly 2 of the P cores are on 100%, and some of the E cores are running various amounts, none 100%. I've had it crash once with 3 threads after i sent the stop_mining command, but a few other times it worked fine.
4 threads were similar and similar perf to 3 threads, and stop_mining crashed it again.
I also notice that sometimes the cmd window starts visually different, in a smaller size/font, idk why.
And rarely, it started up noticeable slower than most other times, in fact i opted to close those and restart monerod.
Next two times, starting the 4 threads crashed it after a few seconds.
Starting it with 0xfff affinity to exclude the E cores and keep only the P cores, starting to mine on 12 threads also crashes it.
4 threads seems to work. 6 thread worked too. starting 7 threads crashed it.
With 0x555 affinity to only include one of the threads of each P core, starting to mine with 6 threads crashes it after a few seconds. 4 threads crashed it like that too. 2 threads seems to work fine. 3 crashed it on start.
With 0xff000 (so only E cores), 1, 2, 3, and 4 threads started and stopped properly once, but then starting 5 threads crashed, and after that starting 4 threads crashed it too.
xmrig mines just fine with all 20 cpu cores/threads if needed, or with less as I configure.
I'm personally fine with xmrig mining at this point, but wanted to report the issue.