0

I have implemented a custom RandomX Pool miner with C++ which even outperforms XMRig. However after submitting a share the miner does not always get a new job instantly. Sometimes it takes several seconds to get a new job. Even calling the RPC method getjob the miner is still waiting several seconds for new jobs. In this time the processor is doing nothing and just wasting time while waiting for a job...

I don‘t think that this issue is related to network latency because after the rpc method login a job is dispatched pretty instantly.

Is there anything I can do to reduce the waiting time for new jobs?

jtgrassie
  • 19,601
  • 4
  • 17
  • 54
FrankTank
  • 3
  • 1

2 Answers2

0

after submitting a share the miner does not always get a new job instantly

The pool will not send you a new job for each share you submit. You keep working on the same job until the pool sends you a new one.

jtgrassie
  • 19,601
  • 4
  • 17
  • 54
0

When you find a share, it means you found a "pseudo" block at a difficulty which matches what the pool requested. This difficulty is almost certainly well below the difficulty required to find an actual block that will be accepted by the Monero network. When you find such a pool-but-not-network block candidate, the pool keeps a record of your find for payout purposes, but the network stays as is, so you continue mining on the same state, and so the pool does not need to send you another job since the one you were working on is still valid.

The pool will usually send you another job on a few conditions:

  • a new block was added to the blockchain
  • the pool has changed the set of transactions to be included in the block to be mined
  • enough time has elapsed that the pool decided to update the timestamp in the block header

If you find a share and it just happens to meet the network difficulty, then you will receive a new job straight away after submitting that share, but since the Monero network difficulty is high, this is very seldom compared to the number of times you submit a share only to continue hashing on the same state.

user36303
  • 34,928
  • 2
  • 58
  • 123