Multiple device groups for MRR still not working

[acos0874]

Hi, I raised an issue before about the multiple workers on one rig not being picked up correctly in recent versions but the recent fix doesn't seem to have solved the problem.

I have a rig with a mixture of 1070s and 1660Tis and the rentals seem to be working when both device groups are rented at the same time but when only one is rented it won't switch to MRR. I'm currently running two instances of RBM to get round it. I've uploaded a copy of the debug file.
Thanks again!

debug_2019-10-29.zip

[RainbowMiner]

Thank you for checking this again. I will fix it asap

[acos0874]

Thank you. To help the search, the MTP rental on the 1660tis ran up until about 3:16am (although there were some jitters around 11pm and 1:30am on both rentals. The C29D then ran consistently till just before 7am when it went down completely and refused to launch (nothing showed up on watchdog).

I also have a rental on a second separate rig that uses a different MRR API key.

[RainbowMiner]

I just noticed, that I had imported a bug into the debug file creation. The config is missing. Would you please send me your current .\Config\config.txt and just the MiningRigRentals part in .\Config\pools.config.txt (please remove wallets and keys and secrets before posting)?

[acos0874]

pools.config - Copy.zip

[RainbowMiner]

Thank you. Could you please send me the .\Config\devices.config.txt , too? Just to be sure.

[acos0874]

devices.config.txt

[acos0874]

Any luck with this please?

[RainbowMiner]

I am having hard times reproducing this. So just to make it clear:

• all rigs (and device-rigs) are being announced at MRR ?
• what happens, if only one half of the rig is being rented? Does the mining start and finish, until end?
• the problem occurs only, if both half of the rig are rented and one rental ends?
• does the remaining rental stop immediate, or does it continue for some time?
• if you restart RainbowMiner, does the remaining rental start?
• the problem never happened before version v4.4.5.0 ? 100% sure? I ask, because I just cannot figure out the difference.

[acos0874]

I've fired up a single instance of RBM running version 4.4.5.4 and all seems fine as both rigs are rented. I'll monitor for the remainder of the rentals. I had wondered if it was an issue with the MRR API but I don't know how I would check that,

[acos0874]

The problem still seems to be there. At around 21:04 the device groups were happily mining on the c29d orders. I've checked the logs and there are no error messages but both workers switched to ethash
INFO: Stopping miner Gminer-GPU#02-GPU#04-GPU#05-GPU#08-GPU#10-GPU#11 on pool MiningRigRentals.
INFO: Miner Gminer-GPU#02-GPU#04-GPU#05-GPU#08-GPU#10-GPU#11 closed gracefully
INFO: Stopping miner Gminer-GPU#01-GPU#03-GPU#06-GPU#07-GPU#09 on pool MiningRigRentals.
INFO: Miner Gminer-GPU#01-GPU#03-GPU#06-GPU#07-GPU#09 closed gracefully
INFO: OC set for NBminer-GTX1070-Ethash: PL=100%, TL=-, MEM=400, CORE=120, LVP=850000µV
INFO: OC set for NBminer-GTX1660Ti-Ethash: PL=100%, TL=80°C, MEM=600, CORE=0, LVP=650000µV
INFO: Starting miner (NBminer-GPU#01-GPU#02-GPU#03-GPU#04-GPU#05-GPU#06-GPU#07-GPU#08-GPU#09-GPU#10-GPU#11):

After 13 intervals the rentals were picked up again and both rigs continued. The only thing I found in the logs that was unusual is this, which occurred at the start of the rentals continuing.

INFO: Pinging monitoring server.
PS>TerminatingError(Invoke-RestMethod): "The underlying connection was closed: A connection that was expected to be kept alive was closed by the server."

TerminatingError(Invoke-RestMethod): "The underlying connection was closed: A connection that was expected to be kept alive was closed by the server."
TerminatingError(Invoke-RestMethod): "The underlying connection was closed: A connection that was expected to be kept alive was closed by the server."
INFO: Miner Status https://rbminer.net/api/report.php has failed.

RainbowMiner_2019-10-31_17-18-22.txt

[acos0874]

I just realised that maybe the issue is due to the renters pool. Is it possible that if something changed in the renters settings then it wouldn't be picked up as an error via the API for RBM but it would severe the connection 'Gracefully'?

[acos0874]

Just noticed my rentals were from two different people. It would be a coincidence if they were both using the same pool when it went down.

[RainbowMiner]

Thank you for this in depth analysis. Actually, RainbowMiner switches to normal Mining for 15 minutes, if a renters pool is offline for 15 minutes. After that time, it will retry to connect to MRR.
Eventually it is a coincidence of same pool. Cuckrood29 mostly mines to one large pool. Anyway, I will do code analysis tomorrow, just to be sure, that one "wait-with-mining" round really does affect the current rental, only.

[acos0874]

Thank you. During the night just one of my rigs picked up a rental. Please see the attached screenshots.
The previous rental ended at 22:57 and the new one started at 03:59 but you can see there's a lot of stopping and starting during the second period. Maybe it's due to combo mode? I'll try disabling it.

[acos0874]

Actually that would make sense because do you think maybe the combo workername conflicts with the workername for the individual devices?

[acos0874]

Just going through the list of active miners. I think the problem might be related to the 'combo over device' option in the config file. It wasn't until recently that I enabled this option again whilst also using MRR. I suspect that it's causing it to override the MRR or something. I've disabled combo mode now and will monitor to see if the problem has gone away.

[acos0874]

OK after a few days of testing with rentals on one device group and both device groups at the same time, the rentals have been fine. I'm 99% certain the problem were either to do with combo mode overriding rental or, more likely, the 'combo over single' setting overriding the rental on either a single or dual rental.

[RainbowMiner]

You were totally right. It's the combo over single feature, that interfered with MRR.