[ANN] TeamRedMiner v0.10.10 - Ironfish/Kaspa/ZIL/Kawpow/Etchash and More

[cryptomaxsun]

I tried running this miner for monero.
I have a videocard RX 480 4 gb, windows 7, driver crimson beta.
The driver crashes, black screen.
This is not the first miner, which I do not run on Monero, the problem is the same everywhere - the crash driver.

[1715433270]

1715433270

[1715433270]

1715433270

[UnclWish]

I tried running this miner for monero.
I have a videocard RX 480 4 gb, windows 7, driver crimson beta.
The driver crashes, black screen.
This is not the first miner, which I do not run on Monero, the problem is the same everywhere - the crash driver.

Then try other driver. This miner works fine on latest...

[Mashy81]

I tried running this miner for monero.
I have a videocard RX 480 4 gb, windows 7, driver crimson beta.
The driver crashes, black screen.
This is not the first miner, which I do not run on Monero, the problem is the same everywhere - the crash driver.

Change to windows 10 and latest drivers. It costs nothing but a bit of time

[kamisama233]

I have kind of a weird behavior with my 0.4.3 version. I've noticed that after a few hours mining the hashrate declines then stabilizes.

On CN-R after 30 mn I have my peak HR @3760H/s (4 RX574), then after 4 hours I get 3715H/s, then 3680 H/s.

Has anybody else the same behaviour from the miner ?

Usually it's one of two things: one or more crashed threads (but only one per gpu so each gpu still hashes with ok-ish speed) or threads that no longer run in a staggered/interleaved way. You can tell which case it is by shutting down - if the miner shuts down clean with no warning log or extra delay, there were no crashed threads.

The former case (crashed threads) needs clock tweaking, something isn't 100% stable. The latter case (no crashed threads) was addressed in v0.4.4 by adding the interleave adjustment logic. It has helped in the vast majority of cases that I've followed up on, but sometimes it can over-adjust instead.

Assuming it's the latter case for you, have you checked if v0.4.4 works better? Or have you tried v0.4.4 and you have some other issue forcing you back to 0.4.3?

[2019-04-27 19:49:26] Stats Uptime: 0 days, 01:02:31
[2019-04-27 19:49:26] GPU 0 [55C, fan 37%] cnr: 1.997kh/s, avg 1.996kh/s, pool 2.444kh/s a:49 r:0 hw:0
[2019-04-27 19:49:26] GPU 1 [52C, fan 39%] cnr: 501.3 h/s, avg 501.1 h/s, pool 529.2 h/s a:10 r:0 hw:0
[2019-04-27 19:49:26] GPU 2 [59C, fan 60%] cnr: 990.7 h/s, avg 990.5 h/s, pool 937.0 h/s a:18 r:0 hw:0
[2019-04-27 19:49:26] GPU 3 [58C, fan 54%] cnr: 1.004kh/s, avg 1.004kh/s, pool 979.7 h/s a:20 r:0 hw:0
[2019-04-27 19:49:26] GPU 4 [55C, fan 39%] cnr: 992.7 h/s, avg 988.8 h/s, pool 1.050kh/s a:21 r:0 hw:0
[2019-04-27 19:49:26] GPU 5 [56C, fan 49%] cnr: 969.2 h/s, avg 971.2 h/s, pool 578.9 h/s a:11 r:0 hw:0
[2019-04-27 19:49:26] Total                cnr: 6.455kh/s, avg 6.452kh/s, pool 6.519kh/s a:129 r:0 hw:0
[2019-04-27 19:49:29] Pool pool.minexmr.com received new job. (job_id: IQadw6QFAK4OGNPLTPy0btC8g8tg)
[2019-04-27 19:49:29] Pool pool.minexmr.com set difficulty to 195181
[2019-04-27 19:51:30] Initializing GPU 0.
[2019-04-27 19:51:30] Runtime Command Keys: h - help, s - stats, e - enable gpu, d - disable gpu, q - quit
[2019-04-27 19:51:30] Watchdog thread starting.
[2019-04-27 19:51:30] API initialized on 0.0.0.0:522
[2019-04-27 19:51:30] Pool pool.minexmr.com connecting to address 103.60.164.109.
[2019-04-27 19:51:30] Pool pool.minexmr.com successfully connected to address 103.60.164.109.
[2019-04-27 19:51:30] Pool pool.minexmr.com login succeeded.(30 ms)
[2019-04-27 19:51:30] Pool pool.minexmr.com received new job. (job_id: jDzNeP7qpABbn5n1hCheh3uGFrUl)
[2019-04-27 19:51:30] Pool pool.minexmr.com set difficulty to 80000
[2019-04-27 19:51:31] Initializing GPU 1.
[2019-04-27 19:51:32] Initialization comm error 4
[2019-04-27 19:51:32] Initializing GPU 2.
[2019-04-27 19:51:33] Dev pool connected and ready.
[2019-04-27 19:51:33] Initializing GPU 3.
[2019-04-27 19:51:33] Miner load at 0%, hashrates are not at max speed yet.
[2019-04-27 19:51:34] Initializing GPU 4.
[2019-04-27 19:51:34] Initializing GPU 5.
[2019-04-27 19:51:35] Successfully initialized GPU 0: Vega with 56 CU (PCIe 06:00.0) (CN 16+14)
[2019-04-27 19:51:35] Successfully initialized GPU 1: Polaris with 12 CU (PCIe 08:00.0) (CN L4+4)
[2019-04-27 19:51:35] Successfully initialized GPU 2: Polaris with 32 CU (PCIe 13:00.0) (CN 8+7)
[2019-04-27 19:51:35] Successfully initialized GPU 3: Polaris with 32 CU (PCIe 14:00.0) (CN 8+7)
[2019-04-27 19:51:35] Successfully initialized GPU 4: Polaris with 32 CU (PCIe 15:00.0) (CN 8+7)
[2019-04-27 19:51:35] Successfully initialized GPU 5: Polaris with 32 CU (PCIe 16:00.0) (CN 8+7)
[2019-04-27 19:51:36] Miner load at 7%, hashrates are not at max speed yet.
[2019-04-27 19:51:39] Miner load at 38%, hashrates are not at max speed yet.
[2019-04-27 19:51:42] Miner load at 60%, hashrates are not at max speed yet.
[2019-04-27 19:51:45] Miner load at 75%, hashrates are not at max speed yet.
[2019-04-27 19:51:48] Miner load at 90%, hashrates are not at max speed yet.
[2019-04-27 19:51:51] Miner load at 100%, hashrates are not at max speed yet.
[2019-04-27 19:51:53] Pool pool.minexmr.com share accepted. (GPU5) (a:1 r:0) (63 ms)
[2019-04-27 19:51:54] Miner load at 100%, initial ramp-up completed.
[2019-04-27 19:51:56] Pool pool.minexmr.com received new job. (job_id: rac0jGgL6PdSZ2M6sbrEK5j0kW83)
[2019-04-27 19:51:56] Pool pool.minexmr.com set difficulty to 96000
[2019-04-27 19:51:59] Pool pool.minexmr.com share accepted. (GPU2) (a:2 r:0) (59 ms)
[2019-04-27 19:52:00] Stats Uptime: 0 days, 00:00:31



Dear developer, two questions
1, the rig reboot without any error, the power was always on, what can be the reason?
2, what's the error message " Initialization comm error 4" mean, what could be the problem?

[kerney666]

I have kind of a weird behavior with my 0.4.3 version. I've noticed that after a few hours mining the hashrate declines then stabilizes.

On CN-R after 30 mn I have my peak HR @3760H/s (4 RX574), then after 4 hours I get 3715H/s, then 3680 H/s.

Has anybody else the same behaviour from the miner ?

Usually it's one of two things: one or more crashed threads (but only one per gpu so each gpu still hashes with ok-ish speed) or threads that no longer run in a staggered/interleaved way. You can tell which case it is by shutting down - if the miner shuts down clean with no warning log or extra delay, there were no crashed threads.

The former case (crashed threads) needs clock tweaking, something isn't 100% stable. The latter case (no crashed threads) was addressed in v0.4.4 by adding the interleave adjustment logic. It has helped in the vast majority of cases that I've followed up on, but sometimes it can over-adjust instead.

Assuming it's the latter case for you, have you checked if v0.4.4 works better? Or have you tried v0.4.4 and you have some other issue forcing you back to 0.4.3?

[2019-04-27 19:49:26] Stats Uptime: 0 days, 01:02:31
[2019-04-27 19:49:26] GPU 0 [55C, fan 37%] cnr: 1.997kh/s, avg 1.996kh/s, pool 2.444kh/s a:49 r:0 hw:0
[2019-04-27 19:49:26] GPU 1 [52C, fan 39%] cnr: 501.3 h/s, avg 501.1 h/s, pool 529.2 h/s a:10 r:0 hw:0
[2019-04-27 19:49:26] GPU 2 [59C, fan 60%] cnr: 990.7 h/s, avg 990.5 h/s, pool 937.0 h/s a:18 r:0 hw:0
[2019-04-27 19:49:26] GPU 3 [58C, fan 54%] cnr: 1.004kh/s, avg 1.004kh/s, pool 979.7 h/s a:20 r:0 hw:0
[2019-04-27 19:49:26] GPU 4 [55C, fan 39%] cnr: 992.7 h/s, avg 988.8 h/s, pool 1.050kh/s a:21 r:0 hw:0
[2019-04-27 19:49:26] GPU 5 [56C, fan 49%] cnr: 969.2 h/s, avg 971.2 h/s, pool 578.9 h/s a:11 r:0 hw:0
[2019-04-27 19:49:26] Total                cnr: 6.455kh/s, avg 6.452kh/s, pool 6.519kh/s a:129 r:0 hw:0
[2019-04-27 19:49:29] Pool pool.minexmr.com received new job. (job_id: IQadw6QFAK4OGNPLTPy0btC8g8tg)
[2019-04-27 19:49:29] Pool pool.minexmr.com set difficulty to 195181
[2019-04-27 19:51:30] Initializing GPU 0.
[2019-04-27 19:51:30] Runtime Command Keys: h - help, s - stats, e - enable gpu, d - disable gpu, q - quit
[2019-04-27 19:51:30] Watchdog thread starting.
[2019-04-27 19:51:30] API initialized on 0.0.0.0:522
[2019-04-27 19:51:30] Pool pool.minexmr.com connecting to address 103.60.164.109.
[2019-04-27 19:51:30] Pool pool.minexmr.com successfully connected to address 103.60.164.109.
[2019-04-27 19:51:30] Pool pool.minexmr.com login succeeded.(30 ms)
[2019-04-27 19:51:30] Pool pool.minexmr.com received new job. (job_id: jDzNeP7qpABbn5n1hCheh3uGFrUl)
[2019-04-27 19:51:30] Pool pool.minexmr.com set difficulty to 80000
[2019-04-27 19:51:31] Initializing GPU 1.
[2019-04-27 19:51:32] Initialization comm error 4
[2019-04-27 19:51:32] Initializing GPU 2.
[2019-04-27 19:51:33] Dev pool connected and ready.
[2019-04-27 19:51:33] Initializing GPU 3.
[2019-04-27 19:51:33] Miner load at 0%, hashrates are not at max speed yet.
[2019-04-27 19:51:34] Initializing GPU 4.
[2019-04-27 19:51:34] Initializing GPU 5.
[2019-04-27 19:51:35] Successfully initialized GPU 0: Vega with 56 CU (PCIe 06:00.0) (CN 16+14)
[2019-04-27 19:51:35] Successfully initialized GPU 1: Polaris with 12 CU (PCIe 08:00.0) (CN L4+4)
[2019-04-27 19:51:35] Successfully initialized GPU 2: Polaris with 32 CU (PCIe 13:00.0) (CN 8+7)
[2019-04-27 19:51:35] Successfully initialized GPU 3: Polaris with 32 CU (PCIe 14:00.0) (CN 8+7)
[2019-04-27 19:51:35] Successfully initialized GPU 4: Polaris with 32 CU (PCIe 15:00.0) (CN 8+7)
[2019-04-27 19:51:35] Successfully initialized GPU 5: Polaris with 32 CU (PCIe 16:00.0) (CN 8+7)
[2019-04-27 19:51:36] Miner load at 7%, hashrates are not at max speed yet.
[2019-04-27 19:51:39] Miner load at 38%, hashrates are not at max speed yet.
[2019-04-27 19:51:42] Miner load at 60%, hashrates are not at max speed yet.
[2019-04-27 19:51:45] Miner load at 75%, hashrates are not at max speed yet.
[2019-04-27 19:51:48] Miner load at 90%, hashrates are not at max speed yet.
[2019-04-27 19:51:51] Miner load at 100%, hashrates are not at max speed yet.
[2019-04-27 19:51:53] Pool pool.minexmr.com share accepted. (GPU5) (a:1 r:0) (63 ms)
[2019-04-27 19:51:54] Miner load at 100%, initial ramp-up completed.
[2019-04-27 19:51:56] Pool pool.minexmr.com received new job. (job_id: rac0jGgL6PdSZ2M6sbrEK5j0kW83)
[2019-04-27 19:51:56] Pool pool.minexmr.com set difficulty to 96000
[2019-04-27 19:51:59] Pool pool.minexmr.com share accepted. (GPU2) (a:2 r:0) (59 ms)
[2019-04-27 19:52:00] Stats Uptime: 0 days, 00:00:31



Dear developer, two questions
1, the rig reboot without any error, the power was always on, what can be the reason?
2, what's the error message " Initialization comm error 4" mean, what could be the problem?

Hi!

In my experience, the most common reason for erratic and sudden reboots is a PSU starting to crap out.

For the error message, it is an error that can occur in our own init procedure. I have addressed in the next release coming out very shortly, it has proper retry logic so even though this error might happen now and then, the miner will retry and hopefully recover. This error happens more often with risers, and even more often when those risers are becoming bad .

[NCarter84]

I've been killing myself over this one... Maybe, someone else from the outside can help me...

I recently upgraded my ATX 1000w PSU to a 1200w server PSU/breakout board. Upon that upgrade, as I was applying my overclocks and such through a bat file with ODnT, my system started freezing. If I applied this settings manually, no issues.

So, I did what any good miner would do.. DDU and start over.. Same thing... I DDU'd a 3rd time and upgraded to the latest drivers along with ODnT 2.8. Since then, my system hasn't had any issues applying the clock n suck through a bat file.

However, my hashrate that the miner shows vs what the miner shows pool side has been off... I've tried different settings in ODnT, lowered memory, more power and none of my tests are matching up..

I will run the miner for 12 hours, get both miner/pool hashrate to match up at 5.5 khs, stop miner, start again and run for 12 more hours and then they aren't matched anymore... 5.5 vs 5.3.... Sometimes the same test will result even worse at 5.2 or 5.1 -- I understand luck is in play, but I don't think luck should effect it this much.

My other rigs show Miner and Pool to be very close..

I have fixed diff at 55000 on Support XMR.

Moddest overclocks.

570s run 1150/875 and memory 1925/875.
580s run 1200/900 and meomry 2000/900.

I'll run the same clocks back to back and get different reported values each time... There are times where I have cards running 300-400 hs less than expected on the pool

I've tried more power, less memory, more memory...

I'm at a loss..

[Hackintoshihope]

I've been killing myself over this one... Maybe, someone else from the outside can help me...

I recently upgraded my ATX 1000w PSU to a 1200w server PSU/breakout board. Upon that upgrade, as I was applying my overclocks and such through a bat file with ODnT, my system started freezing. If I applied this settings manually, no issues.

So, I did what any good miner would do.. DDU and start over.. Same thing... I DDU'd a 3rd time and upgraded to the latest drivers along with ODnT 2.8. Since then, my system hasn't had any issues applying the clock n suck through a bat file.

However, my hashrate that the miner shows vs what the miner shows pool side has been off... I've tried different settings in ODnT, lowered memory, more power and none of my tests are matching up..

I will run the miner for 12 hours, get both miner/pool hashrate to match up at 5.5 khs, stop miner, start again and run for 12 more hours and then they aren't matched anymore... 5.5 vs 5.3.... Sometimes the same test will result even worse at 5.2 or 5.1 -- I understand luck is in play, but I don't think luck should effect it this much.

My other rigs show Miner and Pool to be very close..

I have fixed diff at 55000 on Support XMR.

Moddest overclocks.

570s run 1150/875 and memory 1925/875.
580s run 1200/900 and meomry 2000/900.

I'll run the same clocks back to back and get different reported values each time... There are times where I have cards running 300-400 hs less than expected on the pool

I've tried more power, less memory, more memory...

I'm at a loss..

Sadly these server PSU’s only output 900W on 120V (normal US output) unless you are on 240V this could explain why you are having power issues as the server psu is not able to output the required power. Please correct me if anything I’ve assumed is wrong.

[kamisama233]

I have kind of a weird behavior with my 0.4.3 version. I've noticed that after a few hours mining the hashrate declines then stabilizes.

On CN-R after 30 mn I have my peak HR @3760H/s (4 RX574), then after 4 hours I get 3715H/s, then 3680 H/s.

Has anybody else the same behaviour from the miner ?

Usually it's one of two things: one or more crashed threads (but only one per gpu so each gpu still hashes with ok-ish speed) or threads that no longer run in a staggered/interleaved way. You can tell which case it is by shutting down - if the miner shuts down clean with no warning log or extra delay, there were no crashed threads.

The former case (crashed threads) needs clock tweaking, something isn't 100% stable. The latter case (no crashed threads) was addressed in v0.4.4 by adding the interleave adjustment logic. It has helped in the vast majority of cases that I've followed up on, but sometimes it can over-adjust instead.

Assuming it's the latter case for you, have you checked if v0.4.4 works better? Or have you tried v0.4.4 and you have some other issue forcing you back to 0.4.3?

[2019-04-27 19:49:26] Stats Uptime: 0 days, 01:02:31
[2019-04-27 19:49:26] GPU 0 [55C, fan 37%] cnr: 1.997kh/s, avg 1.996kh/s, pool 2.444kh/s a:49 r:0 hw:0
[2019-04-27 19:49:26] GPU 1 [52C, fan 39%] cnr: 501.3 h/s, avg 501.1 h/s, pool 529.2 h/s a:10 r:0 hw:0
[2019-04-27 19:49:26] GPU 2 [59C, fan 60%] cnr: 990.7 h/s, avg 990.5 h/s, pool 937.0 h/s a:18 r:0 hw:0
[2019-04-27 19:49:26] GPU 3 [58C, fan 54%] cnr: 1.004kh/s, avg 1.004kh/s, pool 979.7 h/s a:20 r:0 hw:0
[2019-04-27 19:49:26] GPU 4 [55C, fan 39%] cnr: 992.7 h/s, avg 988.8 h/s, pool 1.050kh/s a:21 r:0 hw:0
[2019-04-27 19:49:26] GPU 5 [56C, fan 49%] cnr: 969.2 h/s, avg 971.2 h/s, pool 578.9 h/s a:11 r:0 hw:0
[2019-04-27 19:49:26] Total                cnr: 6.455kh/s, avg 6.452kh/s, pool 6.519kh/s a:129 r:0 hw:0
[2019-04-27 19:49:29] Pool pool.minexmr.com received new job. (job_id: IQadw6QFAK4OGNPLTPy0btC8g8tg)
[2019-04-27 19:49:29] Pool pool.minexmr.com set difficulty to 195181
[2019-04-27 19:51:30] Initializing GPU 0.
[2019-04-27 19:51:30] Runtime Command Keys: h - help, s - stats, e - enable gpu, d - disable gpu, q - quit
[2019-04-27 19:51:30] Watchdog thread starting.
[2019-04-27 19:51:30] API initialized on 0.0.0.0:522
[2019-04-27 19:51:30] Pool pool.minexmr.com connecting to address 103.60.164.109.
[2019-04-27 19:51:30] Pool pool.minexmr.com successfully connected to address 103.60.164.109.
[2019-04-27 19:51:30] Pool pool.minexmr.com login succeeded.(30 ms)
[2019-04-27 19:51:30] Pool pool.minexmr.com received new job. (job_id: jDzNeP7qpABbn5n1hCheh3uGFrUl)
[2019-04-27 19:51:30] Pool pool.minexmr.com set difficulty to 80000
[2019-04-27 19:51:31] Initializing GPU 1.
[2019-04-27 19:51:32] Initialization comm error 4
[2019-04-27 19:51:32] Initializing GPU 2.
[2019-04-27 19:51:33] Dev pool connected and ready.
[2019-04-27 19:51:33] Initializing GPU 3.
[2019-04-27 19:51:33] Miner load at 0%, hashrates are not at max speed yet.
[2019-04-27 19:51:34] Initializing GPU 4.
[2019-04-27 19:51:34] Initializing GPU 5.
[2019-04-27 19:51:35] Successfully initialized GPU 0: Vega with 56 CU (PCIe 06:00.0) (CN 16+14)
[2019-04-27 19:51:35] Successfully initialized GPU 1: Polaris with 12 CU (PCIe 08:00.0) (CN L4+4)
[2019-04-27 19:51:35] Successfully initialized GPU 2: Polaris with 32 CU (PCIe 13:00.0) (CN 8+7)
[2019-04-27 19:51:35] Successfully initialized GPU 3: Polaris with 32 CU (PCIe 14:00.0) (CN 8+7)
[2019-04-27 19:51:35] Successfully initialized GPU 4: Polaris with 32 CU (PCIe 15:00.0) (CN 8+7)
[2019-04-27 19:51:35] Successfully initialized GPU 5: Polaris with 32 CU (PCIe 16:00.0) (CN 8+7)
[2019-04-27 19:51:36] Miner load at 7%, hashrates are not at max speed yet.
[2019-04-27 19:51:39] Miner load at 38%, hashrates are not at max speed yet.
[2019-04-27 19:51:42] Miner load at 60%, hashrates are not at max speed yet.
[2019-04-27 19:51:45] Miner load at 75%, hashrates are not at max speed yet.
[2019-04-27 19:51:48] Miner load at 90%, hashrates are not at max speed yet.
[2019-04-27 19:51:51] Miner load at 100%, hashrates are not at max speed yet.
[2019-04-27 19:51:53] Pool pool.minexmr.com share accepted. (GPU5) (a:1 r:0) (63 ms)
[2019-04-27 19:51:54] Miner load at 100%, initial ramp-up completed.
[2019-04-27 19:51:56] Pool pool.minexmr.com received new job. (job_id: rac0jGgL6PdSZ2M6sbrEK5j0kW83)
[2019-04-27 19:51:56] Pool pool.minexmr.com set difficulty to 96000
[2019-04-27 19:51:59] Pool pool.minexmr.com share accepted. (GPU2) (a:2 r:0) (59 ms)
[2019-04-27 19:52:00] Stats Uptime: 0 days, 00:00:31



Dear developer, two questions
1, the rig reboot without any error, the power was always on, what can be the reason?
2, what's the error message " Initialization comm error 4" mean, what could be the problem?

Hi!

In my experience, the most common reason for erratic and sudden reboots is a PSU starting to crap out.

For the error message, it is an error that can occur in our own init procedure. I have addressed in the next release coming out very shortly, it has proper retry logic so even though this error might happen now and then, the miner will retry and hopefully recover. This error happens more often with risers, and even more often when those risers are becoming bad .

thanks

[NCarter84]

I've been killing myself over this one... Maybe, someone else from the outside can help me...

I recently upgraded my ATX 1000w PSU to a 1200w server PSU/breakout board. Upon that upgrade, as I was applying my overclocks and such through a bat file with ODnT, my system started freezing. If I applied this settings manually, no issues.

So, I did what any good miner would do.. DDU and start over.. Same thing... I DDU'd a 3rd time and upgraded to the latest drivers along with ODnT 2.8. Since then, my system hasn't had any issues applying the clock n suck through a bat file.

However, my hashrate that the miner shows vs what the miner shows pool side has been off... I've tried different settings in ODnT, lowered memory, more power and none of my tests are matching up..

I will run the miner for 12 hours, get both miner/pool hashrate to match up at 5.5 khs, stop miner, start again and run for 12 more hours and then they aren't matched anymore... 5.5 vs 5.3.... Sometimes the same test will result even worse at 5.2 or 5.1 -- I understand luck is in play, but I don't think luck should effect it this much.

My other rigs show Miner and Pool to be very close..

I have fixed diff at 55000 on Support XMR.

Moddest overclocks.

570s run 1150/875 and memory 1925/875.
580s run 1200/900 and meomry 2000/900.

I'll run the same clocks back to back and get different reported values each time... There are times where I have cards running 300-400 hs less than expected on the pool

I've tried more power, less memory, more memory...

I'm at a loss..

Sadly these server PSU’s only output 900W on 120V (normal US output) unless you are on 240V this could explain why you are having power issues has the server psu is not able to output the required power. Please correct me if anything I’ve assumed is wrong.

That is correct.

However, I'm only running 5 cards on that psu and the total wattage pulled is under 700w.

So, I'm not sure if we can pin it on that.

[pbfarmer]

I've been killing myself over this one... Maybe, someone else from the outside can help me...

I recently upgraded my ATX 1000w PSU to a 1200w server PSU/breakout board. Upon that upgrade, as I was applying my overclocks and such through a bat file with ODnT, my system started freezing. If I applied this settings manually, no issues.

So, I did what any good miner would do.. DDU and start over.. Same thing... I DDU'd a 3rd time and upgraded to the latest drivers along with ODnT 2.8. Since then, my system hasn't had any issues applying the clock n suck through a bat file.

However, my hashrate that the miner shows vs what the miner shows pool side has been off... I've tried different settings in ODnT, lowered memory, more power and none of my tests are matching up..

I will run the miner for 12 hours, get both miner/pool hashrate to match up at 5.5 khs, stop miner, start again and run for 12 more hours and then they aren't matched anymore... 5.5 vs 5.3.... Sometimes the same test will result even worse at 5.2 or 5.1 -- I understand luck is in play, but I don't think luck should effect it this much.

My other rigs show Miner and Pool to be very close..

I have fixed diff at 55000 on Support XMR.

Moddest overclocks.

570s run 1150/875 and memory 1925/875.
580s run 1200/900 and meomry 2000/900.

I'll run the same clocks back to back and get different reported values each time... There are times where I have cards running 300-400 hs less than expected on the pool

I've tried more power, less memory, more memory...

I'm at a loss..

First, your pool and miner rate should technically not match.  There's a 2.5% fee on CNR, so 5.3 is actually closer to the proper pool rate than 5.5.

Second, 12 hours is generally not even enough time to have confidence in a stable rig.  It's definitely not enough time to get anywhere near a high level of confidence in an actual representative pool rate - you simply aren't submitting enough shares to make a proper measurement in that short of time.  By my math, you would need more like 5 days for a ~99% confidence in your reported pool rate being truly representative, at your h/r and diff.

[kerney666]

Team Red Miner v0.4.5 released

https://github.com/todxx/teamredminer/releases

Changes in v0.4.5

• Added cryptonight v8 upx2 for the uPlexa coin fork.
• Reworked init procedure, added retry logic on comm errors.
• Added section on temps to the CN_MAX_YOUR_VEGA guide.
• Added a new howto MAP_YOUR_GPUS describing how to map gpus between miner/tools/registry.

Standard best configs for cnv8-upx2 is the same as for CN-turtle:

• Vega 64 L28+28
• Vega 56 L24+24
• 580-470 L16+16

As always, these are usually the optimal settings but your mileage may vary!

For Vegas at 1407@900/1107@900 with modded mem timings you should hit 84-86 kh/s, without mem timings 75 kh/s. For Polaris and others you can choose yourself if you want to save power and run with the same hashrate as other miners, or increase your core clk to 1230-1300 to increase the hashrate but still consume less power.

If you haven't used Vegas with modded mem timings before, check the CN_MAX_YOUR_VEGA.txt guide in the release.

[NCarter84]

I've been killing myself over this one... Maybe, someone else from the outside can help me...

I recently upgraded my ATX 1000w PSU to a 1200w server PSU/breakout board. Upon that upgrade, as I was applying my overclocks and such through a bat file with ODnT, my system started freezing. If I applied this settings manually, no issues.

So, I did what any good miner would do.. DDU and start over.. Same thing... I DDU'd a 3rd time and upgraded to the latest drivers along with ODnT 2.8. Since then, my system hasn't had any issues applying the clock n suck through a bat file.

However, my hashrate that the miner shows vs what the miner shows pool side has been off... I've tried different settings in ODnT, lowered memory, more power and none of my tests are matching up..

I will run the miner for 12 hours, get both miner/pool hashrate to match up at 5.5 khs, stop miner, start again and run for 12 more hours and then they aren't matched anymore... 5.5 vs 5.3.... Sometimes the same test will result even worse at 5.2 or 5.1 -- I understand luck is in play, but I don't think luck should effect it this much.

My other rigs show Miner and Pool to be very close..

I have fixed diff at 55000 on Support XMR.

Moddest overclocks.

570s run 1150/875 and memory 1925/875.
580s run 1200/900 and meomry 2000/900.

I'll run the same clocks back to back and get different reported values each time... There are times where I have cards running 300-400 hs less than expected on the pool

I've tried more power, less memory, more memory...

I'm at a loss..

First, your pool and miner rate should technically not match.  There's a 2.5% fee on CNR, so 5.3 is actually closer to the proper pool rate than 5.5.

Second, 12 hours is generally not even enough time to have confidence in a stable rig.  It's definitely not enough time to get anywhere near a high level of confidence in an actual representative pool rate - you simply aren't submitting enough shares to make a proper measurement in that short of time.  By my math, you would need more like 5 days for a ~99% confidence in your reported pool rate being truly representative, at your h/r and diff.

You actually nailed it on the head.... After doing the math, I forgot about the dev fee and was in panic mode because numbers weren't matching up... After reviewing all the test data, Every run was at 97% or better return hashrate except 1...

Thanks!

[rednoW]

2 kerney666

Can you please make txt files with correct new line symbol for windows version (in teamredminer-v0.4.5-win.zip file)?
It is real pain to read in std notepad )))

[kerney666]

2 kerney666

Can you please make txt files with correct new line symbol for windows version (in teamredminer-v0.4.5-win.zip file)?
It is real pain to read in std notepad )))

Ah man, that is just so annoying. I write those files in Notepad++ under Windows, they get Windows newlines. Then, we commit them into our git repo, where newlines are normalized to Unix style. Then, depending on which OS you check out the repo on, you get Windows or Unix newlines. We build our releases under Linux with cross-compilation for Windows, meaning they will be checked out and shipped with Unix-style newlines. Need to add a little dos2unix/unix2dos before bundling, thanks for pointing this out, had totally missed it myself...

[Mashy81]

Team Red Miner v0.4.5 released

https://github.com/todxx/teamredminer/releases

Changes in v0.4.5

• Added cryptonight v8 upx2 for the uPlexa coin fork.
• Reworked init procedure, added retry logic on comm errors.
• Added section on temps to the CN_MAX_YOUR_VEGA guide.
• Added a new howto MAP_YOUR_GPUS describing how to map gpus between miner/tools/registry.

Standard best configs for cnv8-upx2 is the same as for CN-turtle:

• Vega 64 L28+28
• Vega 56 L24+24
• 580-470 L16+16

As always, these are usually the optimal settings but your mileage may vary!

For Vegas at 1407@900/1107@900 with modded mem timings you should hit 84-86 kh/s, without mem timings 75 kh/s. For Polaris and others you can choose yourself if you want to save power and run with the same hashrate as other miners, or increase your core clk to 1230-1300 to increase the hashrate but still consume less power.

If you haven't used Vegas with modded mem timings before, check the CN_MAX_YOUR_VEGA.txt guide in the release.

I was hopeful that you would do upx and you didn't dissapoint. I will try it out in a few hours time 😁

[KL0nLutiy1]

@kerney666, whet MTP support?

[dragonmike]

@kerney666, whet MTP support?

Funny we were just talking about MTP yesterday...
What's the best AMD MTP miner so far? Andrucrypt had had a go early but stopped development. Has djm34 made any decent effort on OpenCL?

If not, this screams for TRM to jump in...

EDIT: but to be perfectly honest, unless you can get at least 3 MH/s out of a Vega GPU (good luck), Zcoin isn't currently profitable enough to justify the work. Of course, market conditions can change.

[MaxHa$h]

2 kerney666

Can you please make txt files with correct new line symbol for windows version (in teamredminer-v0.4.5-win.zip file)?
It is real pain to read in std notepad )))

.

just open it in word pad and it will all correct!

[Mashy81]

Nice work on upx2. I only get 80khs on v64 or 77khs on same power level as srb (which I get 65khs).

Would love to see you guys kill it on MTP

[joseph32]

@kerney666, whet MTP support?

Funny we were just talking about MTP yesterday...
What's the best AMD MTP miner so far? Andrucrypt had had a go early but stopped development. Has djm34 made any decent effort on OpenCL?

If not, this screams for TRM to jump in...

EDIT: but to be perfectly honest, unless you can get at least 3 MH/s out of a Vega GPU (good luck), Zcoin isn't currently profitable enough to justify the work. Of course, market conditions can change.

Tested the latest djm34 version with Vega64's. Stable, but just 1.5 MH/s only. Not worth atm.

I would also love to see MTP, but anything below 3 MH/s for Vega64 makes no sence (as you said too).