13:44:52 started getting a bunch of errors when compiling stuff on the beagle board. Also noticed a particular "hot metal" smell. So now just waiting on delivery of some cooling kit, damn thing was toasty! 13:45:27 while I wait for the heatsinks and a little fan to arrive, going to design and 3d print a case/frame for it 13:59:11 I'm running my board without a heatsink. And it was running at full load for over 3 days when testing RandomX without issues. These small SoCs are quite power efficient. 14:01:42 it was just the processor that was hot, the memory and supporting components all seemed well within temp 14:02:29 I mean it was still running fine, but not a big fan of things that hot running so close to my keyboard :D 14:03:49 fresh install, clean boot, and it was still under a decent load. Once the kit comes and I've got the case designed and printed, I'll look to disabling the GUI on boot and see if I can get the ethernet working 18:52:14 hmmk. round 2 of compiling xmrig on the beagle 18:59:36 my 10M run took 20hr53min. hash matches. 19:01:11 pauliouk: yeah I noticed my chip was pretty hot on the old July firmware. it's much cooler on the new firmware. dunno what was running behind the scenes since top showed idle system. maybe GPU was infinite looping. 19:04:37 I killed xfce and setup it up to single user boot, load averages dropped from ~1.5 to 0.2 idle 19:04:53 made a heck of a difference to the temperature 19:05:34 struggling to get xmrig to make though :| cc: error: unrecognized command-line option '-maes' 19:07:09 that's only for x86 19:07:37 cmake must not be recognizing your architecture 19:07:46 xmrig only knows x86 and arm, so it probably defaults to x86 command line options when it doesn't recognize the platform 19:08:47 oh right, xmrig, not randomx 19:08:50 is there also a nice option to cmake with everything but randomx disabled? :P 19:13:25 was there anything special you needed to do to get it to compile on the Lychee? 19:22:15 I've only built randomx. not xmrig 19:22:29 ah gotcha 19:33:07 yup running a 1000 nonces verify benchmark... heatsink would make a nice coffee warmer 19:34:47 so did bitmain modify the xmrig code to get it working on the X5, or did they do something custom with the ARM version, having the hashboards handle the work? 19:35:37 no idea 19:36:21 any advantage to software AES using a 128 bit vector register instead of 4 32bit ints ? 19:36:37 should be plenty of 'spares and repairs' without working hashboards on the markets soon enough by the sounds of it :D 19:42:02 ah I see OpenSSL has an AES impl for ARMv8 NEON. for Rpi of course. constant time tho, which we don't really care about here 19:46:39 hmm beagleboard: 977.392 ms per none 19:46:42 *nonce 19:47:51 Performance: 977.392 ms per hash 19:50:36 then in JIT compiled mode: 101.591 ms per hash 19:57:50 and 77.3565 ms per hash with lage pages 19:59:10 hyc no idea how fast it is, but here's what I found: https://git.kernel.org/pub/scm/linux/kernel/git/ardb/linux.git/tree/arch/arm64/crypto/aes-neon.S 20:00:20 8 threads, JIT, large pages. 23.2746 ms per hash 20:25:12 sech1 just thinking about whether to port that to the C910 20:27:21 pauliouk: about 43.5H/s, sounds right 20:27:57 hmmm, 8 threads? 20:28:26 yup - ROI, running from now until my great-great-great-grandkids discover it 20:28:46 it's only a quadcore chip, why 8 threads?\ 20:29:11 I'll try it on 4 20:29:18 23.1482 ms per hash 20:34:44 SiFive announcing new higher perf chips https://www.theregister.com/2023/10/11/sifive_riscv_cores/ 20:34:58 still, gets around the same hashrate as the $30 android tv boxes do :P 20:35:20 "ms per hash" means you are using the light mode 20:37:30 not sure how well this would run in regular mode to be fair 20:37:57 why not? 4GB RAM 20:38:58 doesn't hurt to try 20:39:32 this is true, whats the option needed? 20:41:29 use --mine 20:41:33 --mine instead of --verify 20:41:49 do the same as in the ticket https://github.com/tevador/RandomX/pull/275 20:41:51 hmm complaining about largepages 20:42:04 Error: Dataset allocation failed 20:42:10 you'll have to up the number of hugepages 20:42:18 you need about 1180 20:42:29 its set for 1250 20:42:50 is something else using them? cat /proc/meminfo 20:43:22 ouch yup 20:45:59 only thing thats really using any memory is docker 20:49:16 running docker on one of these boxes seems a bit excessive 20:49:42 default beagle ubuntu install :/ 20:50:48 hmmk, it does not like booting in multi-user mode :/ 20:50:58 check sudo sysctl vm.nr_hugepages to see how many you actually have 20:54:54 damn thing isn't playing ball, waiting for the debug console to wake up 20:59:06 your default install is ubuntu? mine is debian sid. Seems their graphics drivers aren't sorted out. glxinfo SEGVs 21:00:34 yup, would have preferred debian, a nice lite version but I'll take what I can get without having to build my own :P 21:00:48 sudo systemctl set-default multi-user.target to get rid of GUI 21:01:21 yup, tis what I did - doesn't look like its booting too happily any more though