04:51:33 <jtgrassie> sech1, gingeropolous, maybe more pools will turn on self-select when I get round to implementing in nodejs-pool for them.
04:52:09 <jtgrassie> I started this last week, just not had time to finish (due to vomiting over JS).
04:53:38 <jtgrassie> There's also a couple of forks of nodejs-pool and the required packages (like node-cryptoforknote-util et al)
04:56:07 <jtgrassie> If I/we could talk say supportxmr into switching it on if I implement, that would be a first big pool with it implemneted.
04:56:23 <jtgrassie> Others might follow.
05:00:33 <cohcho> Do you see any regular pattern (i.e. wave)  on the first image here: https://minexmr.com/pools.html?
06:09:47 <sech1> cohcho waves are daily cycles. Either botnets or hobby miners who turn off PC for the night.
06:18:39 <cohcho> Do you have updated plot of `nonce.txt` for this hardfork?
06:26:10 <cohcho> Does this patch to bc_dyn_stats in monerod will show the same hashrate as your script for N recent blocks: https://paste.debian.net/plainh/893a5ec8?
06:28:27 <sech1> It should, formula is the same
06:29:54 <cohcho> `bc_dyn_stats 440` says  Height: 1981278, 842.52MH/s with that patch
06:57:38 <cohcho> Looks like randomx library has been loaded into memory from buffer successfuly. 5 days doesn't sound like a reasonable amount of time but anyway it's done.
10:20:57 <sech1> Almost, almost: https://en.wikichip.org/wiki/hisilicon/kunpeng/920-6426
10:20:58 <sech1> Only L3 cache is not enough
10:21:38 <sech1> Each core is custom design based on Cortex-A72, it should be pretty efficient on RandomX
10:22:48 <hyc> yeah, most ARM designs are still light on cache
10:23:07 <hyc> Phytium still seems to be the only design that has adequate cache per core
10:24:05 <sech1> But Kunpeng is almost there, it has everything. It can mine Wownero already at full potential
10:24:29 <sech1> Give it a couple of years and we'll see server and desktop ARM CPUs with 2 MB cache per core
10:25:19 <sech1> It even has 8 memory channels
10:26:51 <sech1> My rough estimate is it should be able to do 450 h/s per thread, 14.4 kh/s with 32 threads
10:27:30 <sech1> at 180 W TDP, 80 h/s per watt
10:27:59 <sech1> maybe less than 180 W because only half of the cores are used
10:57:41 <cohcho> What way did you find this link? (It has been posted here already several times)
11:38:16 <Inge-> 80 h/s os on par for 3900x
11:38:29 <Inge-> is*
12:52:47 <sech1> 1 GH/s incoming
12:53:47 <Inge-> according to your algo?
12:53:51 <Inge-> .network
12:56:38 <sech1> XMR network hashrate 60 : 1,032.329 MH/s
12:56:40 <sech1> last 60 blocks
12:56:52 <cohcho> fortunero.net tests winner at 191313 and it was ~800MH/s at that time
12:57:29 <cohcho> height 1981482, bc_dyn_stats 60 says 1.04GH/s here too
12:57:47 <Inge-> There is a growing suspicion that it is your algorithm that is increasing the hashrate, sech1!
12:58:18 <sech1> Well, there's going to be one more speed boost for old Xeons/Opterons
12:58:51 <sech1> I just need to test it to get numbers
12:59:02 <cohcho> 1918313*
12:59:50 <sech1> 1981313?
13:00:03 <Inge-> how old?
13:00:22 <Inge-> the E5 got a decent jump from 5.0.1 -> 5.1
13:00:34 <sech1> Westmere, Sandy Bridge, IviBridge
13:00:38 <sech1> so v1, v2 Xeons and older
13:00:50 <sech1> v3 and newer won't get big speedup
13:01:17 <sech1> but they'll also get small 1% speedup
13:02:07 <cohcho> fixed type in fortunero.net related sentence
13:02:28 <sech1> yes, you fixed but still got the number wrong :D
13:03:20 <cohcho> yes, 8 and 1 should be swapped
14:05:17 <gingeropolous> oooh, old opterons get a boost!?!?!?!
14:05:43 <gingeropolous> time to turn on those banshees