search

MoneroOcean / xmrig

Monero (rx/0, rx/wow, rx/loki, defyx, rx/arq, rx/sfx, rx/keva, cn/0, cn/1, cn/2, cn/r, cn/fast, cn/half, cn/xao, cn/rto, cn/rwz, cn/zls, cn/double, cn/gpu, cn-lite/0, cn-lite/1, cn-heavy/0, cn-heavy/tube, cn-heavy/xhv, cn-pico, cn-pico/tlo, argon2/chukwa, argon2/wrkz, astrobwt) CPU/GPU miner
https://moneroocean.stream
GNU General Public License v3.0
272 stars 84 forks source link

xmrig-mo doesn't support client.reconnect #92

Open PSLLSP opened 2 years ago

PSLLSP commented 2 years ago

xmrig-v6.16.2-mo2-lin64-compat.tar.gz

It looks like xmrig-mo doesn't support client.reconnect.

Config file to replicate the issue. It is expected that worker TEST3333 will be reconnected from TCP port 3333 to other port (like 50821). Worker TEST50821 is a workarround, it is there only because switching doesn't work. 

$ cat config-rtm-test.json
{
  "autosave": false,
  "cpu": true,
  "opencl": false,
  "cuda": false,
  "pools": [
    { 
      "algo": "ghostrider",
      "url": "eu-de01.miningrigrentals.com:3333",
      "user": "droidMiner.217649",
      "pass": "TEST3333",
      "keepalive": true,
      "enabled": true
    },
    { 
      "algo": "ghostrider",
      "url": "eu-de01.miningrigrentals.com:50821",
      "user": "droidMiner.217649",
      "pass": "TEST50821",
      "keepalive": true,
      "enabled": true
    }
  ]
}
$ ./xmrig --bench-algo-time=1 -c config-rtm-test.json
...
[2022-01-14 04:36:47.350]  benchmk   ALGO PERFORMANCE CALIBRATION COMPLETE 
[2022-01-14 04:36:48.132]  net      eu-de01.miningrigrentals.com:3333 read error: "end of file"
[2022-01-14 04:36:53.344]  net      eu-de01.miningrigrentals.com:3333 read error: "end of file"

You can check issue #2846 of original xmrig for more details. The issue has an example of cpuminer-opt-gr that works as expected (it reconnects from TCP port 3333 to 50821)...

Spudz76 commented 2 years ago

This is because the fix I submitted has been merged into dev but this fork is always based on master

The fix will trickle down whenever the next time upstream rolls a new master, because that will trigger a new MO-fork release. Usually they roll it up a bit more often... or this bug was not considered bad enough to reroll immediately... or there is need to leave it on "test" basis longer, to help ensure the patch didn't break something else (with the subset of users that run dev branch normally, like me).

Otherwise you could subscribe to my dev-mo branch which is whatever the current MoneroOcean:master is but applied to current upstream dev. But then you have to compile your own since I don't build any releases on my fork. And I don't think anyone builds binaries from dev.

This also has no effect on MO-fork being used on MO-pool which is its intended target (or liberty-pool or others that also support algo-perf on login, but would never use the reconnect command). So then the main issue is just that this fix is not yet in master so that it could be in any release binaries. The upstream releases should also fail this test, it is not MO-specific.

PSLLSP commented 2 years ago

OK, I can wait. I didn't know that the fix will be pulled from xmrig repo on next release, so I opened this issue here. It is not critical bug but it affects some pools with advanced configuration. I am looking forward for the future release that will fix this small issue so a workaround with custom TCP port will not be required anymore...

PSLLSP commented 2 years ago

I tested with xmrig-v6.16.5-mo1-lin64.tar.gz and this issue is not fixed... :-( Upstream xmrig was fixed a month ago.

$ sudo ./xmrig --bench-algo-time=1 -c config-rtm-test.json
 * ABOUT        XMRig/6.16.5-mo1 gcc/9.3.0
 * LIBS         libuv/1.34.2 OpenSSL/1.1.1f hwloc/2.4.1
...
[2022-04-09 11:36:59.109]  benchmk   ALGO PERFORMANCE CALIBRATION COMPLETE 
Aborted