<gingeropolous> "im betting a second p2pool is..." <- We should come up with a name for og-p2pool soon

sechistheone

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?

yeah i think its just different port

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

If you want to switch pools, you set the pool name and connect to an IP of a known peer in that pool?

s/set/change/

There is already an unique id created based on consensus parameters crypto_grampy[m]

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)

Hey everyone

I'm noticing the number of upstreams on my xmrig proxy keeps increasing, while the number of miners remains the same

[2021-11-04 09:27:28.308] proxy 150.00 kH/s, shares: 4/0 +0, upstreams: 24, miners: 24 (max 24) +0/-0

[2021-11-04 09:28:28.568] proxy 100.00 kH/s, shares: 4/0 +0, upstreams: 27, miners: 24 (max 24) +3/-3

Then I also notice that p2pool actually sends work items 1 for each upstream

Is it normal that I receive more upstreams than workers? are these upstreams garbage collected somehow?

<sech1> if you run xmrig-proxy in simple mode then 1 upstream = 1 miner

<sech1> it probably keeps an upstream for a while after miner disconnects

yes, I use it in simple mode, as I understand this is the way to run it with p2pool

I've never seen the upstream number go down eventually

hyc sech1 everyone

damn

not bad - expensive bit of kit I'm guessing?

needs optimization or prolly latency too high

pauliouk: 5400 is pretty low end for ddr5

7000 at the topend with an xOC 2 dimmer board

they say 6400 is attainable by most chips on the daily

<sech1> phoronix.com/scan.php?page=article&item=intel-12600k-12900k&num=3

sech1

<sech1> so ~8.9 kh/s on Monero and ~10.4 kh/s on Wownero

<sech1> just as I expected

sech1: okay man, done with that bench, maybe youll get more in a few days heh

gonna bother the guy for other stuff now

sech1: did it run properly?

<sech1> looks like it did

sech1: p-cores have avx512 but for now intel disabled it since windows cant handle it

like e-cores dont have it

so when running certain stuff it uhhhh

illegal instruction

intel will likely re-enable it idk

<sech1> avx512 is a waste

an early asus bios enables you to toggle it and it loads an older microcode and it disables the e-cores

<sech1> better have more smaller cores without avx512

intel is still gonna try to enable it

but yeah, needs software support

just a heads up

sech1: i cant promise a 1t run as it takes too much time and evryone is asking those guy to run meme benchmarks

maybe domorrow ill get the guy to run 1t

sech1: interested on an avx512 run or is it really useless for you?

<sech1> useless

<sech1> also: 3dnews.ru/assets/external/illustrations/2021/11/04/1052960/memlat.png

kk

<sech1> huge L3 latency

<sech1> 1T RandomX will be bad

how many minutes do you expect for 1M?

1t 1M

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

<sech1> probably ~900 h/s, so 17-19 minutes

lmao

so rocketlake still 1t king

<sech1> 1t can wait

kk

yeah good thing this guy woke up on time now

and i got the first benchmark after nda lift

<sech1> 40 cycles on Zen3 vs 65 cycles on Alder Lake

sech1: im still impressed on the performance though

not bad for the first try of big little on x86

im sure there will be growing pains but yeah, not bad

intel is back man

intel is back

So 12900 = 3700

for mining ye

intel still a cachelet

sech1: are you able to reproduce the core_tests crash on arm64/jit ?

<sech1> I only have RPi4 and it overheats under prolonged load and then reboots or hangs

sech1, want me to send you a heat sink kit and 3v fan? :) keeps mine running

<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 🙂

fresh air is always a plus I guess :)

sech1: you seem spot on, guy said its doing 900 h.s on 1t

based sech1

anyway, we will finish the bench

sech1 xmrig.com/benchmark/7Kp9ny

ok I'm running under gdb again, will grab disasssembly when it dies

folks please use #monero-mining or something for general p2pool usage stuff

this channel should be development focused

sech1: paste.debian.net/1218230

there is also #p2pool-log for p2pool chatter

let me know if you want more context before/after there

paste.debian.net/1218231 same thing, with hex bytes

so it was a call to randomx_calc_dataset_item_aarch64 that landed in unmapped memory

it looks like linker bug to me

or no, it's not a linker bug. randomx_calc_dataset_item_aarch64 is copied to allocated memory to construct super scalar hash code

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

randomx::CodeSize = 13464

randomx::CalcDatasetItemSize = 66308

the memory region is 81920 bytes, should have been large enough for all of that

the target address is far below the beginning of the region

+++++++++++++

sech1 what values do you get in your build?

these values look correct. I need to remember how it's actually JITted

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

maybe linker error

can you try compiling and running xmrig there? It has the same code there

afaik this only fails in core_tests

this box is currently running both monerod and p2pool, so this code is already live on the box

I have previously run xmrig on here without any problems either

maybe I can figure out how to set a watchpoint on that branch instr and trap when it gets overwritten

or I wonder if there's just garbage in there left over from a previous testcase

What's the minimal reproduction you have ?

`tests/core_tests/core_tests --generate_and_play_test_data --filter gen_block_big_major_version` does it fail with this filter ?

did you try to reduce it to single rx_slow_hash call ?

if it's a linker error, just calling rx_slow_hash from anywhere within that binary should cras

*crash

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

this instruction should be unique enough to find RandomX code

running now with the filter

SEGv'd again

different stacktrace tho

#0 0x0000ffffe1d6f438 in ?? ()

only 1 stack frame, nothing else

can you set preliminary breakpoint on rx_slow_hash, it must be the first call

ok trying again with breakpoint

hit breakpoint, now what?

`finish`

segv

set breakpoint on randomx_calculate_hash

and step manually

there will be few steps before actual jit

and then likely few instructions within jit and segv

ok running

cache init stage is not interesting, it can be even commented probably

the actual JIT code execution starts at "compiler.getProgramFunc()(reg, mem, scratchpad, RANDOMX_PROGRAM_ITERATIONS);" in vm_compiled.cpp

yeah I'm stepping thru asm code now

this could take a while, one instr at a time

ok, segv

gahh. the process disappeared, can't inspect memory*////

trying again. cat was on kbd

`one instr at a time` you could do `99999 si` and `1 si` and then bisect actual number of instructions before seg

but `si` is useful only within jit, c++ can be stepped with simple `step`

ok I have it

well, the jump offset is the same in both cases

yes. the execution was completely linear from 91000 to 91b38

then it branched to 94430

I mean the bl instruction that jump to unmapped memory

yeah it's the same bytes as before

it's probably linker bug

I blame binutils again

hmmm

IIRC we had problem with it on ARM before

does ARM on Mac use JIT?

yes

so this is gnu ld 2.34

ubuntu 20.04.2 lts

"github.com/tevador/RandomX/blob/mas…/src/jit_compiler_a64_static.S#L434" it's this place in jit, right ?

yes

here's where the previous 2 add instructions are updated: github.com/tevador/RandomX/blob/master/src/jit_compiler_a64.cpp#L224

but jump instruction is not touched there

hmmmm

that symbol is not present in the .o file

oh there it is

maybe reordering chunks in the source file would avoid the problem

disassemble this randomx_program_aarch64_light_dataset_offset, what is the destination of relative jump there ? is it randomx_calc_dataset_item_aarch64 ?

you can disassemble executable with objdump / gdb / anything else

sure

it is <randomx_calc_dataset_item_aarch64@plt>

it's treating it as an external global, not a local reference

that would explain the problem, it needs to jump thru the plt to get fixed up to the correct address

and jit is doing stupid memcpy of asm with assumption that it's PIE

and that's not happening here

PIC (position independent code)

yes

dunno how to force the asm to emit a relative branch here

it should be PIC

`as -fPIC ...` ?

it's a local jump within the same .S file

well, it has assembled as a global reference, not a local

probably because randomx_calc_dataset_item_aarch64 is used in jit_compiler_a64.cpp

but it should've optimized it to relative jump during linking

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

or just give randomx_calc_dataset_item_aarch64 2 labels, one local

yeah, but how you can be sure it's the only place like this

maybe it's first of many

hmmm. ok will objdump the .o

actually they're all declared as globel (see first lines of jit_compiler_a64_static.S)

they appear to be relocatable references in the .o file instead of relative

"github.com/tevador/RandomX/blob/mas…r/src/jit_compiler_x86_static.S#L94"

"paste.debian.net/hidden/9831a12f" build with clang and shared libs failed on some jump within jit too

and it was x86_64

I'm going to insert a bunch of local labels in here and see if it makes a difference

"libera.monerologs.net/monero-pow/20210819" steps to reproduce

yes, inserting and using local labels works, the global references are gone

test succeeds

can you patch x86_64 jit, i'll repeat the above test with clang

* ... write patch for x86_64 jit and share it ...

ok, gimme a couple minutes

fyi github.com/hyc/RandomX/tree/relocs

I'll add the x86 patch to this branch

works

I'm fixing up one more reference

line 151

rx_dataset_init

that seems to be all

I presume the .asm file should get the same change

maybe

I guess randomx_dataset_init was safe because it's within the same function

but whatever, I changed it already, will leave it in

ok, branch updated. we need someone to build on windows to test the .asm file

not me

yeah, I don't have recent msvc here either

is running randomx-tests enough?

probably

(don't know if that uses jit)

I can run it on Windows CI

cool. but is it actually building with msvc or with gnu toolchain?

the last unanswered question, why did it fail only within core_tests ?

or mebbe I should just leave the .asm source untouched, since nobody has reported a crash in windows

probably because it's dynamic linking librandomx.so

wfaressuissia: in a static build there would be no PLT reference

dunno

can verify this hypothesis somehow quickly ? via build logs maybe

I didn't build tests on my release build, lemme check

release build def builds static librarry, debug build uses shared library

core_tests fails independently on build type (debug/release), right ?

actually I had a lot of similar problems with debug MSVC builds

it always replaced pointer to functions to pointers to jmp instructions that jumped to actual functions

ok, then the .asm patch should prob help

wfaressuissia: I suppose it would still fail on release build if it assembled an absolute addr reference instead of a relative one

why monerod works independently on build type then ?

link time optimization?

core_tests and monerod are both executables in the end, what's the difference ?

dunno

the release build definitely assembled absolute references on master

but monerod binary has relative references there

gdb monerod ; disass/r randomx_program_aarch64_light_dataset_offset

so monerod works because the linker did the right thing there

what bit to flip in order to get the same problem in monerod as in core_tests ?

* which bit ...

good question

my release build of core_tests doesn't crash. the code has a relative reference

so it's only a problem with dynamic librandomx.so

then all questions are answered