the whole project is built around async calls and libuv event loop, so I'm not so sure :)

Hi All, I was reading about Monero and mining and came across p2pool. The concept seems pretty good atleast with my limited understanding. One statement somewhere in their website stumped me. They support only primary addresses. Why does it matter, I mean an address is an address no?

no

Okay that was succinct 😀. Let me progress a little more on mastering monero and get back.

plenty of info on stackexchange

just search for subaddress

Thank you hyc

I wonder if it would be worthwhile to make calcpow a binary rpc instead of json. ideally it should be as low latency as possible.

rpc vs binary will make <0.01% difference, hash calculation is the slowest

btw I wrote the code for p2pool during breakfast, will be testing it today :D

and p2pool has good support for json rpc and nothing for binary

hyc SChernykh/p2pool #78

it will complain about calling uv_default_loop() from the wrong thread every time

I'll to fix it later because it's not thread safe

but you can test already

hyc SChernykh/p2pool #78 should be good for testing now

nice I'll give it a whirl

this might be quite neat for running many instances of p2pool indeed

yes, my second p2pool instance failed to allocate huge pages even though my server has 64 GB RAM. Memory fragmentation and I don't want to reboot it

slightly higher latency probably

also does it do the check via RPC on light mode?

cause if I feed many p2pool instances to single monerod node, I'm afraid it might not keep up on light mode

monerod uses light mode by default

hyc said something about adding a command line or ENV var option to monerod to fix it

also this RPC API makes it possible to run p2pool+monerod on a 1 GB Raspberry Pi :D

hm. p2pool just hanging at startup

oh wait n/m

yeah something not moving

all the hasher threads waiting for rpc completion

cond_wait

hmm, there's more than one thread?

I might need more than 1 cond var :D

yes

doh

prob going to have to serialize the entire thing, I don't think monerod supports more than 1 outstanding rpc on a connection

each request creates a separate connection

ah

I don't see anything weird on the monerod side

but if each request uses its own resources then yes, each thread needs its own condvar

would be nice to avoid the overhead of creating/destroying mutex&condvar on each request

hyc SChernykh/p2pool cbd3d7d

like this for now

overhead is little compared to RPC delay

and after initial sync, it will calculate PoW only when receiving new sidechain blocks (or Stratum shares with enough difficulty), so it's not so many calls

ok, running again now

still something stuck

no active pools, stop mining - so xmrig is not getting a reply from p2pool

2021-11-20 16:15:19.9117 Util background jobs running:

P2PServer::handle_incoming_block_async (3)

StratumServer::on_share_found (1)

still stuck in cond_wait. any chance the rpc on monerod side isn't returning a valid message?

guess I'll try tcpdumping a bit

p2pool would show something if JSON response was invalid

hyc I added logging of JSON requests/replies

you could also try to move "MutexLock lock(m_loopMutex);" to the very top of RandomX_Hasher_RPC::calculate() to serialize everything

it will be easier to debug

I don't see calc_pow in the packet trace at all

maybe the req isn't actually getting flushed to the network

and tcpdump on loopback interface should be seeing it all

if it's not even sent, probably event loop is not running. Check p2pool log for "RandomX_Hasher event loop started" and "RandomX_Hasher event loop stopped"

yeah, says it started

4 requests are logged

nothing else

4 connections established too. dunno why I don't see it in packet traces

ok, try to add some logging in JSONRPCRequest::on_connect(). Like LOGINFO(1, "JSONRPCRequest::on_connect");

is it possibly sending garbage? I'm seeing some stuff that doesn't look likvalid rpc traffic

maybe a cmd buffer goes away before it got sent?

it's copied in JSONRPCRequest constructor

it wouldn't work with other RPC requests if it wasn't copied

ok. well I see the other requests like get_version get_miner_data

Strange. It worked on Windows. I'll check Linux tomorrow

ok. I filtered on loopback interface, port 18081. calc_pow is not in the capture at all

I see get_info, get_version, get_miner_data, get_block_header_by_height, get_block_headers_range, no other requests

event loop doesn't work for some reason

last attempt: try to remove ", &m_loop" from github.com/SChernykh/p2pool/blob/calcpow/src/pow_hash.cpp#L457

it will fall back to the default loop then

ok

it's not thread-safe, but it should work

it complains

2021-11-20 17:04:44.7250 Util uv_default_loop() can only be used by the main thread. Fix the code!

as expected

but does it send requests?

still seems stuck. i didn't capture pkts, lemme try again

nope. not in packet trace

hm, it may be working now\

I'm seeing results, yes

massively delayed

delay before sending request or when waiting for response?

2 minutes btw first request and first response

I think it's delay before sending request

add log to JSONRPCRequest::on_connect in json_rpc_request.cpp. It should connect immediately, not after 2 minutes

LOGINFO(1, "JSONRPCRequest::on_connect"); should be enough to see it in log and figure out delays

it does connect immediately

it doesn't send request tho

maybe uv_tcp_nodelay doesn't really work

I see a connection open on port 47240 -> 18081 at 17:11:59

the request on port 47240 happens at 17:14:04

but do you have log in on_connect? It will show when p2pool actually gets notified about established connection

ok I'll add that

I see lots of on_connect logs

it looks like it only moves forward after receiving new miner data

and after that it works fine

still seems a long delay between logging the request and actually sending it

17:24:44.2795 request sent, 17:24:44.3041 response receive

not long

are you sure that is the response to that request?

no

ok, it's the previous one

monerod seems to not accept multiple connections

netstat shows 4 established

but it serializes them

I guess. that's still not the real problem tho

does this always use a new connection per RPC? can it reuse the same connection?

ohh I think I know what's happening. libuv loops are really not designed to work in more than 1 thread

the loop is just waiting on a set of handles, and m_loop is waiting on just 1 async handle (m_shutdownAsync)

and it stays asleep even if there's a pending connection request (uv_tcp_connect)

it'll start processing it only after it's woken up (by anything)

this is why it works with uv_default_loop, but with huge delay

new Monero block probably triggers uv_default_loop

fix coming soon

ok

need uv_async_send() ?

yes

hyc submitted the fix, try again

ok building

there it goes :)

you can use uv_async_init with a NULL callback

ok

overall doesn't seem to bad. job acceptance is about as fast as before but occasionally spikes if monerod was busy

share accept times reported by xmrig ...

The current code is still not thread-safe (RPC call adds more handles to loop's list and it can interfere with the loop processing TCP packets and traversing that same list)

I'll rewrite it to use async callback since async is there already

ok

freeing up 512MB of RAM on this rockpro64 is good ...

ahh, I just made it serialized

then I don't need to juggle with async calls

whatever works

this way when JSONRPCRequest::call modifies loop's handle list, the loop is guaranteed to not be doing anything

also I can use only 1 cond var again

cool

can you test again with latest?

ok lemme grab it

running. it's going

nice

yeah looks good