xmrigCC cannot connect to TCP port 3333 at MiningRigRentals (MRR)

[PSLLSP]

xmrigCC-3.0.0-linux-generic-static-arm64.tar.gz

It looks like xmrigCC doesn't support client.reconnect.

Test config, worker TEST3333 doesn't work (the BUG). It should reconnect to TCP port 50821 (or other port, this is customer allocated port). Worker TEST50821 is in config file for reference, it is a workarround until TEST3333 config is fixed. xmrigCC should be able to mine with TEST50821 disabled...

$ 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
        }
    ]
}

This is how the log looks like, xmrigCC cannot connect to TCP port 3333 (because it ignores client.reconnect request):

$ ./xmrigDaemon -c config-rtm-test.json
...
[2022-01-14 02:43:08.844]  net      use pool eu-de01.miningrigrentals.com:3333  188.166.161.62
[2022-01-14 02:43:08.849]  net      eu-de01.miningrigrentals.com:3333 read error: "end of file"
[2022-01-14 02:43:08.850]  net      no active pools, stop mining

#2846 of xmrig has an example configuration for cpuminer-opt-gr that works as expected.

[Bendr0id]

Hi, thanks for your report. It was already fixed in the upstream XMRig-dev branch and is already merged into my dev branch. Will be fixed in the next release.

Regards,

[Bendr0id]

Should be fixed with 3.1.0

[PSLLSP]

I already tested it with xmrig-6.16.3 It works. I tested xmrgCC 3.1.0, it works too.

Current implementation is great improvement and it works, miner responses to client.reconnect. I do not like the way how the client.reconnect was implemented in xmrig; it is not critical, I just think that it can be done in better way. I like miner cpuminer-opt-rplant, it switches to new port in nicer way. I already described my point of view few days ago at this issue https://github.com/doktor83/SRBMiner-Multi/issues/90, the last comment has detail description. In short, client.reconnect in xmrig (and clones) is slow. Messages in log could confuse user, reconnection looks like an communication error.

Demo:

#!/bin/sh

POOL="eu-de01.miningrigrentals.com:3333"
#POOL="eu-de01.miningrigrentals.com:50821"

USER="droidMiner.217649"
PASS="TEST5"

ALGO="ghostrider"
OPTS="-k"

#./xmrig -a "$ALGO" -o "$POOL" -u "$USER" -p "$PASS" $OPTS "$@"
./xmrigDaemon -a "$ALGO" -o "$POOL" -u "$USER" -p "$PASS" $OPTS "$@"

Output:

[2022-01-30 19:31:53.942] Please configure CC-Url and restart. CC feature is now deactivated.
[2022-01-30 19:31:53.982]  net      use pool eu-de01.miningrigrentals.com:3333  188.166.161.62
[2022-01-30 19:31:53.985]  net      eu-de01.miningrigrentals.com:3333 client.reconnect to eu-de01.miningrigrentals.com:50821
[2022-01-30 19:31:53.985]  net      no active pools, stop mining
[2022-01-30 19:31:53.986]  net      eu-de01.miningrigrentals.com:3333 read error: "end of file"
[2022-01-30 19:32:00.116]  net      use pool eu-de01.miningrigrentals.com:50821  188.166.161.62
[2022-01-30 19:32:00.116]  net      new job from eu-de01.miningrigrentals.com:50821 diff 13108 algo ghostrider height 238785
[2022-01-30 19:32:00.118]  msr      register values for "intel" preset have been set successfully (2 ms)
[2022-01-30 19:32:01.713]  cpu      use profile  ghostrider  (3 threads) scratchpad 2048 KB

Switch from port 3333 to 50821 took about 6 seconds! I assume there was no waittime parameter to delay reconnect sent from the pool and miner like cpuminer-opt-rplant can switch in just about 1 second... waittime is an optional parameter for client.reconnect.

BTW, I miss a parameter to debug communication with the pool, to see in detail what was received from the pool and what was miner response. That is why I assume that there was no waittime parameter in client.reconnect, I am not sure. I know, I can record communication with a tool like tcpdump... cpuminer-opt-rplant has support for easy protocol troubleshooting, -P, --protocol-dump verbose dump of protocol-level activities.

[Bendr0id]

Thanks for your detailed description. That was the fastest way of implementing it. I agree the "error" is indeed not nice but i think if you expect it and it would be fast it is more then sufficient.

I think you're missing this parameter -R, --retry-pause=N time to pause between retries (default: 5)

That's where you at least lose 5s.

Please retry with setting it to 1 or 0.

Regards,