00:20:23 <crypto_grampy[m]> <gingeropolous> "im betting a second p2pool is..." <- We should come up with a name for og-p2pool soon
00:23:06 <nioc> sechistheone
00:27:27 <crypto_grampy[m]> I like that.  If someone creates a new pool, would it just use a different port?  How do you know which p2pool you're  on if there are multiple?
00:43:05 <gingeropolous> yeah i think its just different port
00:48:15 <crypto_grampy[m]> I don't understand this stuff at all, but would it make any sense to add a unique id?  So everyone who wants to start their own p2pool uses the same port, but you connect with peers that run with the same unique id... I.e. pool name which could be sechistheone 
00:49:05 <crypto_grampy[m]> If you want to switch pools, you set the pool name and connect to an IP of a known peer in that pool?
00:50:10 <crypto_grampy[m]> s/set/change/
05:39:13 <DataHoarder> There is already an unique id created based on consensus parameters crypto_grampy[m] 
05:40:13 <DataHoarder> the issue with more p2pool is 51% attacks that just grab rewards gingeropolous (they can’t do anything Monero wise, just change what shares get paid)
12:41:12 <minereni_d> Hey everyone
12:41:39 <minereni_d> I'm noticing the number of upstreams on my xmrig proxy keeps increasing, while the number of miners remains the same
12:41:50 <minereni_d> [2021-11-04 09:27:28.308]  proxy    150.00 kH/s, shares: 4/0 +0, upstreams: 24, miners: 24 (max 24) +0/-0
12:41:58 <minereni_d> [2021-11-04 09:28:28.568]  proxy    100.00 kH/s, shares: 4/0 +0, upstreams: 27, miners: 24 (max 24) +3/-3
12:42:34 <minereni_d> Then I also notice that p2pool actually sends work items 1 for each upstream
12:43:04 <minereni_d> Is it normal that I receive more upstreams than workers? are these upstreams garbage collected somehow?
12:44:05 <hv-bridge> <sech1> if you run xmrig-proxy in simple mode then 1 upstream = 1 miner
12:44:54 <hv-bridge> <sech1> it probably keeps an upstream for a while after miner disconnects
12:48:21 <minereni_d> yes, I use it in simple mode, as I understand this is the way to run it with p2pool
12:48:49 <minereni_d> I've never seen the upstream number go down eventually
13:01:02 <\x> hyc sech1 everyone
13:01:03 <\x> https://xmrig.com/benchmark/762KY3
13:01:52 <pauliouk> damn
13:02:23 <pauliouk> not bad - expensive bit of kit I'm guessing?
13:02:23 <\x> needs optimization or prolly latency too high
13:02:35 <\x> pauliouk: 5400 is pretty low end for ddr5
13:02:47 <\x> 7000 at the topend with an xOC 2 dimmer board
13:02:57 <\x> they say 6400 is attainable by most chips on the daily
13:14:33 <hv-bridge> <sech1> https://www.phoronix.com/scan.php?page=article&item=intel-12600k-12900k&num=3
13:15:52 <\x> https://hwbot.org/submission/4846628_hocayu_memory_frequency_ddr5_sdram_4352.3_mhz
13:15:55 <\x> sech1
13:18:28 <hv-bridge> <sech1> so ~8.9 kh/s on Monero and ~10.4 kh/s on Wownero
13:18:32 <hv-bridge> <sech1> just as I expected
13:26:14 <\x> sech1: okay man, done with that bench, maybe youll get more in a few days heh
13:26:23 <\x> gonna bother the guy for other stuff now
13:26:36 <\x> sech1: did it run properly?
13:44:28 <hv-bridge> <sech1> looks like it did
13:46:40 <\x> sech1: p-cores have avx512 but for now intel disabled it since windows cant handle it
13:46:49 <\x> like e-cores dont have it
13:47:01 <\x> so when running certain stuff it uhhhh
13:47:05 <\x> illegal instruction
13:47:12 <\x> intel will likely re-enable it idk
13:47:36 <hv-bridge> <sech1> avx512 is a waste
13:47:37 <\x> an early asus bios enables you to toggle it and it loads an older microcode and it disables the e-cores
13:47:47 <hv-bridge> <sech1> better have more smaller cores without avx512
13:47:55 <\x> intel is still gonna try to enable it
13:48:02 <\x> but yeah, needs software support
13:48:16 <\x> just a heads up
13:48:44 <\x> sech1: i cant promise a 1t run as it takes too much time and evryone is asking those guy to run meme benchmarks
13:48:55 <\x> maybe domorrow ill get the guy to run 1t
13:55:35 <\x> https://i.imgur.com/Pewg31V.png
13:55:49 <\x> sech1: interested on an avx512 run or is it really useless for you?
13:56:30 <hv-bridge> <sech1> useless
13:56:33 <hv-bridge> <sech1> also: https://3dnews.ru/assets/external/illustrations/2021/11/04/1052960/memlat.png
13:56:34 <\x> kk
13:56:38 <hv-bridge> <sech1> huge L3 latency
13:56:43 <hv-bridge> <sech1> 1T RandomX will be bad
13:56:56 <\x> how many minutes do you expect for 1M?
13:56:59 <\x> 1t 1M
13:57:32 <\x> i just cant bother the guy to run a long benchmark for now, every fucker on the room is asking for 3dmark stuff with weird settings
13:57:33 <hv-bridge> <sech1> probably ~900 h/s, so 17-19 minutes
13:57:33 <\x> lmao
13:57:44 <\x> so rocketlake still 1t king
13:57:45 <hv-bridge> <sech1> 1t can wait
13:57:48 <\x> kk
13:58:08 <\x> yeah good thing this guy woke up on time now
13:58:19 <\x> and i got the first benchmark after nda lift
13:58:22 <hv-bridge> <sech1> 40 cycles on Zen3 vs 65 cycles on Alder Lake
14:01:44 <\x> sech1: im still impressed on the performance though
14:01:54 <\x> not bad for the first try of big little on x86
14:02:04 <\x> im sure there will be growing pains but yeah, not bad
14:02:08 <\x> intel is back man
14:02:10 <\x> intel is back
14:04:54 <nioc> So 12900 = 3700
14:05:19 <\x> for mining ye
14:05:32 <\x> intel still a cachelet
14:08:47 <hyc> sech1: are you able to reproduce the core_tests crash on arm64/jit ?
14:37:21 <hv-bridge> <sech1> I only have RPi4 and it overheats under prolonged load and then reboots or hangs
14:57:46 <pauliouk> sech1, want me to send you a heat sink kit and 3v fan? :) keeps mine running
14:58:28 <hv-bridge> <sech1> I have a heat sink there. It only works fine if I open the window and put my RPi4 under cold air from the street 🙂
14:59:39 <pauliouk> fresh air is always a plus I guess :)
16:09:01 <\x> sech1: you seem spot on, guy said its doing 900 h.s on 1t
16:09:06 <\x> based sech1
16:09:13 <\x> anyway, we will finish the bench
16:28:30 <\x> sech1 https://xmrig.com/benchmark/7Kp9ny
17:20:02 <hyc> ok I'm running under gdb again, will grab disasssembly when it dies
17:21:08 <hyc> folks please use #monero-mining or something for general p2pool usage stuff
17:21:34 <hyc> this channel should be development focused
17:29:44 <hyc> sech1: https://paste.debian.net/1218230/
17:29:44 <nioc> there is also #p2pool-log for p2pool chatter
17:30:06 <hyc> let me know if you want more context before/after there
17:32:14 <hyc> https://paste.debian.net/1218231/ same thing, with hex bytes
17:40:23 <sech1> so it was a call to randomx_calc_dataset_item_aarch64 that landed in unmapped memory
17:40:29 <sech1> it looks like linker bug to me
17:42:43 <sech1> or no, it's not a linker bug. randomx_calc_dataset_item_aarch64 is copied to allocated memory to construct super scalar hash code
17:45:37 <sech1> hyc you need to print out CodeSize and CalcDatasetItemSize to see how much it allocates. It uses pointer differences between function pointer, maybe it's actually some linker magic that breaks things
17:48:00 <hyc> randomx::CodeSize = 13464
17:48:44 <hyc> randomx::CalcDatasetItemSize = 66308
17:54:39 <hyc> the memory region is 81920 bytes, should have been large enough for all of that
17:55:39 <hyc> the target address is far below the beginning of the region
17:55:56 <hyc> +++++++++++++
17:57:44 <hyc> sech1 what values do you get in your build?
18:05:04 <sech1> these values look correct. I need to remember how it's actually JITted
18:16:58 <sech1> hyc that "bl      0xffffe1f70438" is definitely wrong, it should jump to 0x0000ffffe1f95... because JIT doesn't overwrite jump destination there. It only overwrite previous two "add" instructions
18:18:47 <sech1> maybe linker error
18:19:20 <sech1> can you try compiling and running xmrig there? It has the same code there
18:41:45 <hyc> afaik this only fails in core_tests
18:42:14 <hyc> this box is currently running both monerod and p2pool, so this code is already live on the box
18:44:25 <hyc> I have previously run xmrig on here without any problems either
18:45:34 <hyc> maybe I can figure out how to set a watchpoint on that branch instr and trap when it gets overwritten
18:46:52 <hyc> or I wonder if there's just garbage in there left over from a previous testcase
18:49:16 <wfaressuissia> What's the minimal reproduction you have ?
18:49:31 <wfaressuissia> `tests/core_tests/core_tests --generate_and_play_test_data --filter gen_block_big_major_version` does it fail with this filter ?
18:49:37 <wfaressuissia> did you try to reduce it to single rx_slow_hash call ?
18:50:04 <sech1> if it's a linker error, just calling rx_slow_hash from anywhere within that binary should cras
18:50:06 <sech1> *crash
18:51:49 <sech1> actually, it's better to search for the machine code "ea 03 00 91" (mov x10, sp) and check what's before it in working binary and crashing binary
18:52:00 <sech1> this instruction should be unique enough to find RandomX code
18:58:06 <hyc> running now with the filter
18:58:37 <hyc> SEGv'd again
18:58:53 <hyc> different stacktrace tho
18:59:11 <hyc> #0  0x0000ffffe1d6f438 in ?? ()
18:59:21 <hyc> only 1 stack frame, nothing else
18:59:57 <wfaressuissia> can you set preliminary breakpoint on rx_slow_hash, it must be the first call
19:00:22 <hyc> ok trying again with breakpoint
19:00:47 <hyc> hit breakpoint, now what?
19:01:00 <wfaressuissia> `finish` 
19:01:24 <hyc> segv
19:02:04 <wfaressuissia> set breakpoint on randomx_calculate_hash
19:02:22 <wfaressuissia> and step manually 
19:02:24 <wfaressuissia> there will be few steps before actual jit
19:02:28 <wfaressuissia> and then likely few instructions within jit and segv
19:02:51 <hyc> ok running
19:02:55 <wfaressuissia> cache init stage is not interesting, it can be even commented probably
19:05:49 <sech1> the actual JIT code execution starts at "compiler.getProgramFunc()(reg, mem, scratchpad, RANDOMX_PROGRAM_ITERATIONS);" in vm_compiled.cpp
19:07:31 <hyc> yeah I'm stepping thru asm code now
19:08:31 <hyc> this could take a while, one instr at a time
19:12:03 <hyc> ok, segv
19:13:21 <hyc> gahh. the process disappeared, can't inspect memory*////
19:15:13 <hyc> trying again. cat was on kbd
19:18:29 <wfaressuissia> `one instr at a time` you could do `99999 si` and `1 si` and then bisect actual number of instructions before seg
19:18:48 <wfaressuissia> but `si` is useful only within jit, c++ can be stepped with simple `step`
19:23:01 <hyc> ok I have it
19:23:56 <hyc> https://paste.debian.net/1218250/
19:27:18 <sech1> well, the jump offset is the same in both cases
19:27:57 <hyc> yes. the execution was completely linear from 91000 to 91b38
19:28:08 <hyc> then it branched to 94430
19:28:37 <sech1> I mean the bl instruction that jump to unmapped memory
19:28:48 <hyc> yeah it's the same bytes as before
19:29:01 <sech1> it's probably linker bug
19:29:06 <sech1> I blame binutils again
19:29:11 <hyc> hmmm
19:29:13 <sech1> IIRC we had problem with it on ARM before
19:29:35 <selsta> does ARM on Mac use JIT?
19:29:42 <hyc> yes
19:29:53 <sech1> https://github.com/tevador/RandomX/pull/128
19:31:21 <hyc> so this is gnu ld 2.34
19:31:50 <hyc> ubuntu 20.04.2 lts
19:34:27 <wfaressuissia> "https://github.com/tevador/RandomX/blob/master/src/jit_compiler_a64_static.S#L434" it's this place in jit, right ?
19:35:33 <sech1> yes
19:36:19 <sech1> here's where the previous 2 add instructions are updated: https://github.com/tevador/RandomX/blob/master/src/jit_compiler_a64.cpp#L224
19:36:28 <sech1> but jump instruction is not touched there
19:39:31 <hyc> hmmmm
19:39:45 <hyc> that symbol is not present in the .o file
19:39:58 <hyc> oh there it is
19:40:42 <hyc> https://paste.debian.net/1218253/
19:42:43 <hyc> maybe reordering chunks in the source file would avoid the problem
19:47:40 <wfaressuissia> disassemble this randomx_program_aarch64_light_dataset_offset, what is the destination of relative jump there ? is it  randomx_calc_dataset_item_aarch64 ?
19:48:22 <wfaressuissia> you can disassemble executable with objdump / gdb / anything else
19:49:00 <hyc> sure
19:49:30 <hyc> it is <randomx_calc_dataset_item_aarch64@plt>
19:49:44 <hyc> it's treating it as an external global, not a local reference
19:50:32 <hyc> that would explain the problem, it needs to jump thru the plt to get fixed up to the correct address
19:50:38 <wfaressuissia> and jit is doing stupid memcpy of asm with assumption that it's PIE
19:50:42 <hyc> and that's not happening here
19:51:13 <wfaressuissia> PIC (position independent code)
19:51:17 <hyc> yes
19:51:33 <hyc> dunno how to force the asm to emit a relative branch here
19:51:54 <sech1> it should be PIC
19:51:57 <wfaressuissia> `as -fPIC ...` ?
19:52:01 <sech1> it's a local jump within the same .S file
19:52:37 <hyc> well, it has assembled as a global reference, not a local
19:53:14 <sech1> probably because randomx_calc_dataset_item_aarch64 is used in jit_compiler_a64.cpp
19:53:28 <sech1> but it should've optimized it to relative jump during linking
19:54:02 <hyc> still, it would be better to just emit it as local and leave it alone. I wonder if reordering so it's not a forward reference would make any difference
19:55:18 <hyc> or just give randomx_calc_dataset_item_aarch64 2 labels, one local
19:55:33 <sech1> yeah, but how you can be sure it's the only place like this
19:55:47 <sech1> maybe it's first of many
19:56:03 <hyc> hmmm. ok will objdump the .o
19:56:25 <sech1> actually they're all declared as globel (see first lines of jit_compiler_a64_static.S)
19:59:32 <hyc> they appear to be relocatable references in the .o file instead of relative
19:59:50 <wfaressuissia> "https://github.com/tevador/RandomX/blob/master/src/jit_compiler_x86_static.S#L94" 
20:00:15 <wfaressuissia> "https://paste.debian.net/hidden/9831a12f/" build with clang and shared libs failed on some jump within jit too
20:00:19 <wfaressuissia> and it was x86_64
20:01:29 <hyc> I'm going to insert a bunch of local labels in here and see if it makes a difference
20:02:16 <wfaressuissia> "https://libera.monerologs.net/monero-pow/20210819" steps to reproduce
20:09:17 <hyc> yes, inserting and using local labels works, the global references are gone
20:09:52 <hyc> test succeeds
20:11:27 <wfaressuissia> can you patch x86_64 jit, i'll repeat the above test with clang
20:11:48 <wfaressuissia> * ... write patch for x86_64 jit and share it ...
20:12:04 <hyc> ok, gimme a couple minutes
20:14:07 <hyc> fyi https://github.com/hyc/RandomX/tree/relocs
20:14:17 <hyc> I'll add the x86 patch to this branch
20:18:49 <wfaressuissia> works
20:19:17 <wfaressuissia> https://paste.debian.net/hidden/e1081be5/
20:20:13 <hyc> I'm fixing up one more reference
20:20:22 <hyc> line 151
20:20:29 <hyc> rx_dataset_init
20:21:00 <hyc> that seems to be all
20:21:51 <hyc> I presume the .asm file should get the same change
20:22:45 <wfaressuissia> maybe
20:25:14 <hyc> I guess randomx_dataset_init was safe because it's within the same function
20:25:35 <hyc> but whatever, I changed it already, will leave it in
20:26:34 <hyc> ok, branch updated. we need someone to build on windows to test the .asm file
20:26:46 <wfaressuissia> not me
20:27:54 <hyc> yeah, I don't have recent msvc here either
20:32:51 <selsta> is running randomx-tests enough?
20:33:40 <hyc> probably
20:33:46 <selsta> (don't know if that uses jit)
20:34:22 <selsta> I can run it on Windows CI
20:35:33 <hyc> cool. but is it actually building with msvc or with gnu toolchain?
20:40:00 <wfaressuissia> the last unanswered question, why did it fail only within core_tests ?
20:40:14 <hyc> or mebbe I should just leave the .asm source untouched, since nobody has reported a crash in windows
20:40:59 <hyc> probably because it's dynamic linking librandomx.so
20:41:13 <hyc> wfaressuissia: in a static build there would be no PLT reference
20:41:39 <hyc> dunno
20:41:56 <wfaressuissia> can verify this hypothesis somehow quickly ? via build logs maybe
20:42:46 <hyc> I didn't build tests on my release build, lemme check
20:47:11 <hyc> release build def builds static librarry, debug build uses shared library
20:53:09 <wfaressuissia> core_tests fails independently on build type (debug/release), right ?
20:54:27 <sech1> actually I had a lot of similar problems with debug MSVC builds
20:54:48 <sech1> it always replaced pointer to functions to pointers to jmp instructions that jumped to actual functions
20:58:14 <hyc> ok, then the .asm patch should prob help
20:59:57 <hyc> wfaressuissia: I suppose it would still fail on release build if it assembled an absolute addr reference instead of a relative one
21:00:38 <wfaressuissia> why monerod works independently on build type then ?
21:01:15 <hyc> link time optimization?
21:01:44 <wfaressuissia> core_tests and monerod are both executables in the end, what's the difference ?
21:01:57 <hyc> dunno
21:02:17 <hyc> the release build definitely assembled absolute references on master
21:06:33 <hyc> but monerod binary has relative references there
21:08:11 <hyc> gdb monerod ; disass/r randomx_program_aarch64_light_dataset_offset
21:08:34 <hyc> so monerod works because the linker did the right thing there
21:09:03 <wfaressuissia> what bit to flip in order to get the same problem in monerod as in core_tests ?
21:09:24 <wfaressuissia> * which bit ...
21:09:31 <hyc> good question
22:27:45 <hyc> my release build of core_tests doesn't crash. the code has a relative reference
22:28:08 <hyc> so it's only a problem with dynamic librandomx.so
22:28:23 <wfaressuissia> then all questions are answered