14:08:31 <hyc> I wonder if we should look into making a unikernel build of this so people can boot up their own dedicated mining ASIC ... :P
14:32:14 <m-relay_> <g​ingeropolous:monero.social> u think we could squeeze more h/s/w from a rig?
14:51:47 <hyc> maybe a tiny bit. mostly because there would be no other code running besides the kernel and the miner. no other processes on the box.
14:53:49 <hyc> we could make things totally turnkey. add a broadcast listener to p2pool, have the miner broadcast to find its p2pool server. just plug it in and it works.
14:54:42 <DataHoarder> like good old game servers :D
14:54:43 <hyc> distribute it on bootable USB flash or microSD cards. 
14:55:30 <DataHoarder> it can even be p2pool agnostic, the broadcast listener can just be something you run on the network to send config
14:55:40 <DataHoarder> sends stratum url and args to queriers
14:55:59 <DataHoarder> target can be anything
14:56:32 <hyc> it could ... but there's no reason to support anything besides p2pool ;)
15:01:09 <DataHoarder> sweep fees might grow considerably past FCMP++ btw, so I'm trying to get some aggregation ongoing via multisig groups on the fly (with fallback txs ahead of time)
15:08:58 <m-relay_> <g​ingeropolous:monero.social> id want to support local daemon mining. i don't use p2pool because of the dust. would rather just accept the variance and have larger outputs
15:10:25 <hyc> fair enough. monerod itself could answer that broadcast query
15:10:58 <DataHoarder> tbh, mining on main gets you way less "dust" as payouts unless you have high hashrate
15:11:16 <DataHoarder> compared to mini/nano etc.
15:11:18 <hyc> we should write an IETF RFC spec for this Dynamic Miner Configurartion Protocol  :P
15:11:41 <DataHoarder> just do UDP broadcast on port 3333
15:12:05 <hyc> the spec part is defining the message format
15:12:14 <DataHoarder> I am suggesting the port
15:12:38 <DataHoarder> let's maybe first find if this "turnkey" solution is that much efficient :P
15:12:53 <hyc> sure. the first attempt can use a hardcoded destination.
15:12:57 <m-relay_> <g​ingeropolous:monero.social> nonsense. cart -> horse
15:13:03 <hyc> LOL
15:14:08 <DataHoarder> at least we have the road defined
15:15:05 <m-relay_> <g​ingeropolous:monero.social> well it could have value for ppl launching massive mining infra. i guess they could just clone images onto drives as is, or pixy boot or whatever
15:15:41 <hyc> sure. but people are doing MSR tweaks and other such stuff for tiney fraction of percent improvements
15:16:03 <hyc> maybe there's a fraction of a percent to be found here too
16:09:33 <sech1> hyc so basically ragerx for p2pool :D
16:09:45 <sech1> the one big problem with that is the lack of drivers
16:09:59 <sech1> no driver for GPU = GPU will be burning energy instead of going to the lowest energy state
16:10:28 <sech1> So need to package at least the latest AMD/NVIDIA drivers to put the GPU to idle
16:12:22 <sech1> hyc I'm still waiting for the review https://github.com/tevador/RandomX/pull/316
16:12:52 <sech1> RandomX v2 is almost done, only more documentation and PPC64 (big endian) intrinsics are left
16:56:33 <plowsof> 👏
18:23:11 <m-relay_> <g​ingeropolous:monero.social> the ipc from zen2 to zen4 is no joke. my monerosim run goes from 9 minutes to 3 minutes.
20:23:10 <sech1> Did a writeup on RandomX v2 changes: https://github.com/SChernykh/RandomX/blob/v2/doc/design_v2.md
20:30:35 <DataHoarder> might indeed be good to get more datapoints there to show the impact on quoted Ryzen 9 3950X
20:35:58 <sech1> Need 3950X test, but I don't have it
20:36:10 <sech1> I took the numbers from XMRig's benchmark page
20:44:18 <m-relay_> <g​ingeropolous:monero.social> i got one.. where are these tests...
20:51:57 <m-relay_> <g​ingeropolous:monero.social> i got em. tryna compile
20:54:34 <m-relay_> <g​ingeropolous:monero.social> oh jesbut. this box is currently a space heater in a far away room thats on a bullshit wifi extender so apt upgrade is gonna be slow
21:53:31 <sech1> You will need to compile the v2 branch from my repo, then run randomx-benchmark with the same command line I used for 9950X. But first run randomx_boost.sh from XMRig scripts, and enable huge pages
21:54:10 <sech1> oh, and the command lines are here https://gist.github.com/SChernykh/6058ecf01c929883b9d19c7eeadc8809
21:54:55 <sech1> https://github.com/xmrig/xmrig/blob/master/scripts/randomx_boost.sh
23:07:22 <m-relay_> <g​ingeropolous:monero.social> of course v2 builds but not v1: https://paste.centos.org/view/1ad72230
23:12:09 <DataHoarder> import via "#include <cstdint.h>" afaik
23:40:27 <sech1> what do you mean not v1? The latest code has everything, you can switch between v1 and v2 with command line
23:40:47 <sech1> old code might have some unfixed issues of course
23:51:16 <eureka> sech1: there is ppc64be JIT now? 
23:52:09 <sech1> No
23:52:29 <sech1> But the interpreter mode might not work if the new intrinsics are wrong
23:56:05 <eureka> hyc back in cnv0 days I used to have a stripped down kernel with bare minimums needed for storage+ethernet, initrd just brought up network, allocated hugepages, started my custom static xmr-stak build (built w/ icc, hot funcs had runtime dispatch for various uarch from westmere - skylake) 
23:56:13 <eureka> nice easy boot and mine setup
23:56:37 <eureka> would be pretty fun to do the same for randomx
23:56:53 <eureka> sech1 I have access to ppc64 host, let me see if I can build and run tests