19:30:43 <sech1> RandomX v2 testing has started: https://gist.github.com/SChernykh/6058ecf01c929883b9d19c7eeadc8809
19:30:53 <sech1> More CPUs will be added soon (tm)
19:34:26 <DataHoarder> how does this feel on your orangepi sech1 :D
19:34:44 <sech1> I need to test it, actually
19:34:54 <sech1> It's heavily memory limited, it doesn't have L3
19:36:18 <sech1> I don't have a way to measure power though
19:36:45 <DataHoarder> usb power meter? :D
19:39:18 <sech1> I have a regular power meter, but it will show 4-5 watts, I guess. It's too rough measurement
19:41:32 <DataHoarder> ah. I have one that does mA and mV precision on their own
19:42:02 <DataHoarder> it is quite precise when I measured it against known samples HOWEVER you literally need to record the screen to get the data out
19:42:39 <sech1> I have go-pro to record the screen at 120 FPS :D
19:43:18 <sech1> Orange Pi RV2 (Ky X1 CPU, software AES): v1 99.3 h/s, v2 67.1 h/s
19:43:28 <sech1> AES hits hard when it's not supported
19:43:48 <sech1> XMRig could do 110 h/s on v1 though
19:44:07 <sech1> This thing has unstable hashrate between launches
19:44:33 <DataHoarder> start measuring 10s after starting :D
19:44:37 <sech1> Even XMRig alternates between 110 and 85 h/s on v1, after each launch
19:44:43 <DataHoarder> damn
19:44:56 <sech1> No, I mean hashrate can be either 85 or 110 in XMRig, and it's stable for hours
19:45:05 <sech1> But you need to restart it several times to get "lucky"
19:45:11 <DataHoarder> that's very odd
19:45:30 <sech1> Same behavior in randomx-benchmark, just with a bit lower hashrates
19:45:39 <DataHoarder> no identifiable cause?
19:45:45 <sech1> Probably memory allocation
19:45:52 <sech1> Maybe some parts of RAM are slower there
19:45:56 <DataHoarder> I wonder if it's due to how - yeah
19:46:08 <DataHoarder> like if some core section crosses a specific physical boundary
19:46:36 <DataHoarder> like scratchpad, allocated on big pages or similar but it's laid out across regions that cause that hit
19:46:42 <sech1> It's a 8 GB model. Maybe the upper 4 GB are slower
19:46:57 <DataHoarder> time to allocate it all
19:46:59 <DataHoarder> and test all regions :P
19:47:01 <DataHoarder> when efi randomx
19:47:49 <DataHoarder> maybe we can make a small kernel module to expose contiguous physical memory allocations via specific rules
19:48:28 <DataHoarder> afaik pagemap tells you where in physical memory your virtual memory map landed at
19:48:42 <DataHoarder> so you can start gathering data for when it's slow/fast via pagemap (can inspect this externally while it's running)