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

[smilodon]

very good miner!my lexa rx550 saphire 2gb elpida memory 575 hash with my custom straps.baffin only 450hash on ethos.why low hashrate baffin?any idea?

We do have a few theories but need to do a separate project to sort it out. It is surprising really. We focused on the lexas this time though, 575 h/s for a 550 2GB is very impressive .

Yes, it's very impressive. For 1 month I was trying to fix the card BIOS and it helps a lot that her memory is Elpida. In Windows with CRYPTONIGHTV7 pi? Anei 550 hash with XMR-Stak 2.4. Respectively the Baffin 570 hash. In Linux the Baffin always had a low hashrate.

What Elpida straps do you use to get that hashrate? I've rx550 baffin 12CU unlocked, gets 520 h/s with 3+3

update.my lexa with L3+2 600 hash on ethos.baffin  450 with  3+3 no change.I use memory timings that processed on my own for 1 month! I didn't find them ready. I'll spare the timings at some point.

ram amount:     1.9G   used: 1.3G   free: 552M
cpu usage / temp / load: 14.9% / 36C / 0.80 0.81 0.75

53°C  Fan: 1.3    Hash: 00.00    01 Baffin RX 560 113-367BF-U22 Elpida
56°C  Fan: 1.8    Hash: 00.00    02 Baffin RX 560 113-367BF-U22 Elpida
56°C  Fan: 1.5    Hash: 00.00    03 Lexa PRO RX 550 113-3672E-UO5 Elpida

possible miner stall: check miner log




2018-11-30 09:50:05] Pool pool.supportxmr.com received new job. (job_id: 8hvmgJRtlkXZzd1zafyE2qh+Wm5l)
[2018-11-30 09:50:05] Pool pool.supportxmr.com set difficulty to 44940
[2018-11-30 09:50:06] Stats Uptime: 0 days, 15:38:35
[2018-11-30 09:50:06] GPU 0 [53C, fan 28%] cnv8: 450.6 h/s, avg 450.6 h/s, pool 435.6 h/s a:554 r:0 hw:0
[2018-11-30 09:50:06] GPU 1 [57C, fan 43%] cnv8: 450.6 h/s, avg 450.5 h/s, pool 432.0 h/s a:549 r:0 hw:0
[2018-11-30 09:50:06] GPU 2 [56C, fan 40%] cnv8: 598.7 h/s, avg 600.7 h/s, pool 630.6 h/s a:799 r:0 hw:0
[2018-11-30 09:50:06] Total                cnv8: 1.500kh/s, avg 1.502kh/s, pool 1.498kh/s a:1902 r:0 hw:0
[2018-11-30 09:50:10] Pool pool.supportxmr.com received new job. (job_id: DTlKS4nz2Q6Q5YR4qEftl7IAwmoi)
[2018-11-30 09:50:36] Stats Uptime: 0 days, 15:39:05
[2018-11-30 09:50:36] GPU 0 [53C, fan 28%] cnv8: 450.6 h/s, avg 450.6 h/s, pool 435.3 h/s a:554 r:0 hw:0
[2018-11-30 09:50:36] GPU 1 [56C, fan 43%] cnv8: 450.5 h/s, avg 450.5 h/s, pool 431.8 h/s a:549 r:0 hw:0
[2018-11-30 09:50:36] GPU 2 [56C, fan 40%] cnv8: 600.8 h/s, avg 600.7 h/s, pool 630.2 h/s a:799 r:0 hw:0
[2018-11-30 09:50:36] Total                cnv8: 1.502kh/s, avg 1.502kh/s, pool 1.497kh/s a:1902 r:0 hw:0

[1715257937]

1715257937

[1715257937]

1715257937

[1715257937]

1715257937

[mZoleee]

Hi Guys.

My "rig" running with the latest version of this miner more than 24 hours, and I have lot of rejected shares.. around 20%
I use two Asus RX580 card, GPU0 is DUAL-OC-4G with Eplida memory, GPU1 is ROG-STRIX-O8G with Hynix memory.
I tried more BIOS mod, and default BIOS and lot of settings, but the results is same... any ideas?

Here is my log:

[2018-11-30 17:36:57] Pool xmr-eu2.nanopool.org share accepted. (GPU1) (a:1558 r:28) (75 ms)
[2018-11-30 17:37:09] Stats Uptime: 1 days, 04:23:05
[2018-11-30 17:37:09] GPU 0 [57C, fan 49%] cnv8: 967.9 h/s, avg 970.2 h/s, pool 936.0 h/s a:797 r:14 hw:0
[2018-11-30 17:37:09] GPU 1 [55C, fan 45%] cnv8: 955.6 h/s, avg 959.2 h/s, pool 893.7 h/s a:761 r:14 hw:0
[2018-11-30 17:37:09] Total                cnv8: 1.924kh/s, avg 1.929kh/s, pool 1.830kh/s a:1558 r:28 hw:0
[2018-11-30 17:37:39] Stats Uptime: 1 days, 04:23:35
[2018-11-30 17:37:39] GPU 0 [56C, fan 49%] cnv8: 970.2 h/s, avg 970.1 h/s, pool 935.7 h/s a:797 r:14 hw:0
[2018-11-30 17:37:39] GPU 1 [55C, fan 45%] cnv8: 955.7 h/s, avg 959.2 h/s, pool 893.4 h/s a:761 r:14 hw:0
[2018-11-30 17:37:39] Total                cnv8: 1.926kh/s, avg 1.929kh/s, pool 1.829kh/s a:1558 r:28 hw:0
[2018-11-30 17:37:41] Pool xmr-eu2.nanopool.org received new job. (job_id: 3089)
[2018-11-30 17:38:09] Stats Uptime: 1 days, 04:24:05
[2018-11-30 17:38:09] GPU 0 [57C, fan 49%] cnv8: 970.1 h/s, avg 970.2 h/s, pool 935.4 h/s a:797 r:14 hw:0
[2018-11-30 17:38:09] GPU 1 [56C, fan 45%] cnv8: 955.6 h/s, avg 959.2 h/s, pool 893.2 h/s a:761 r:14 hw:0
[2018-11-30 17:38:09] Total                cnv8: 1.926kh/s, avg 1.929kh/s, pool 1.829kh/s a:1558 r:28 hw:0
[2018-11-30 17:38:23] Pool xmr-eu2.nanopool.org received new job. (job_id: 3090)
[2018-11-30 17:38:31] Pool xmr-eu2.nanopool.org received new job. (job_id: 3091)
[2018-11-30 17:38:31] Pool xmr-eu2.nanopool.org share rejected. (GPU0) Error code: -1 - Block expired (a:1558 r:29) (39 ms)
[2018-11-30 17:38:39] Stats Uptime: 1 days, 04:24:35
[2018-11-30 17:38:39] GPU 0 [57C, fan 49%] cnv8: 970.1 h/s, avg 970.1 h/s, pool 935.1 h/s a:797 r:15 hw:0
[2018-11-30 17:38:39] GPU 1 [54C, fan 43%] cnv8: 955.6 h/s, avg 959.2 h/s, pool 892.9 h/s a:761 r:14 hw:0
[2018-11-30 17:38:39] Total                cnv8: 1.926kh/s, avg 1.929kh/s, pool 1.828kh/s a:1558 r:29 hw:0
[2018-11-30 17:38:44] Pool xmr-eu2.nanopool.org received new job. (job_id: 3092)
[2018-11-30 17:39:09] Pool xmr-eu2.nanopool.org share accepted. (GPU0) (a:1559 r:29) (76 ms)

I use Win10-64Bit-Crimson-ReLive-Beta-Blockchain-Workloads-Aug23 (17.30.1029) driver version.

My lauch command is:

teamredminer.exe -a cnv8 -o stratum+tcp://xmr-eu2.nanopool.org:14444 -u hereismylongestideverseen.mz -p x -d 0,1 --cn_config 6+7,7+8 --pool_broken_rpc --watchdog_script=miner_watchdog.bat --log_file=miner_log.txt

What is the "rejected share" exactly?

[smilodon]

Pool xmr-eu2.nanopool.org share rejected. (GPU0) Error code: -1 - Block expired ......maby high difficulty blocks.up from  70-80.000 is high for  900 hash.

[kerney666]

Hi Guys.

My "rig" running with the latest version of this miner more than 24 hours, and I have lot of rejected shares.. around 20%
I use two Asus RX580 card, GPU0 is DUAL-OC-4G with Eplida memory, GPU1 is ROG-STRIX-O8G with Hynix memory.
I tried more BIOS mod, and default BIOS and lot of settings, but the results is same... any ideas?

Here is my log:

...
[2018-11-30 17:39:09] Pool xmr-eu2.nanopool.org share accepted. (GPU0) (a:1559 r:29) (76 ms)

What is the "rejected share" exactly?

A rejected share is simply when the pool does not accept a share that you find and submit. The most common reason is that the share is submitted for an old job. CN jobs on the gpu take a while to compute, so in some cases a new job is sent out right before a job completes. Added network latency exaggerates the effect.

However, you don't have 20% rejected shares, you rather have 29/(1559+29) = 1.83% rejected shares. I'd say it's on the high side, but nothing too crazy. I don't know Nanopool's policy for accepting shares for jobs for the same network block height though.

[mZoleee]

Hi Guys.

My "rig" running with the latest version of this miner more than 24 hours, and I have lot of rejected shares.. around 20%
I use two Asus RX580 card, GPU0 is DUAL-OC-4G with Eplida memory, GPU1 is ROG-STRIX-O8G with Hynix memory.
I tried more BIOS mod, and default BIOS and lot of settings, but the results is same... any ideas?

Here is my log:

...
[2018-11-30 17:39:09] Pool xmr-eu2.nanopool.org share accepted. (GPU0) (a:1559 r:29) (76 ms)

What is the "rejected share" exactly?

A rejected share is simply when the pool does not accept a share that you find and submit. The most common reason is that the share is submitted for an old job. CN jobs on the gpu take a while to compute, so in some cases a new job is sent out right before a job completes. Added network latency exaggerates the effect.

However, you don't have 20% rejected shares, you rather have 29/(1559+29) = 1.83% rejected shares. I'd say it's on the high side, but nothing too crazy. I don't know Nanopool's policy for accepting shares for jobs for the same network block height though.

Ohh.. good to know. So, probably this is ok.
I checked nanopool site, and site say my last 24 hour hashrate is ~2000h/s..
It seems everything good.

Other question.. Can I generate log, with time filename when I start the miner? example filename: 2018_11_30_19_00.log

[mrpenta]

Hi Guys.

My "rig" running with the latest version of this miner more than 24 hours, and I have lot of rejected shares.. around 20%
I use two Asus RX580 card, GPU0 is DUAL-OC-4G with Eplida memory, GPU1 is ROG-STRIX-O8G with Hynix memory.
I tried more BIOS mod, and default BIOS and lot of settings, but the results is same... any ideas?

Here is my log:

...
[2018-11-30 17:39:09] Pool xmr-eu2.nanopool.org share accepted. (GPU0) (a:1559 r:29) (76 ms)

What is the "rejected share" exactly?

A rejected share is simply when the pool does not accept a share that you find and submit. The most common reason is that the share is submitted for an old job. CN jobs on the gpu take a while to compute, so in some cases a new job is sent out right before a job completes. Added network latency exaggerates the effect.

However, you don't have 20% rejected shares, you rather have 29/(1559+29) = 1.83% rejected shares. I'd say it's on the high side, but nothing too crazy. I don't know Nanopool's policy for accepting shares for jobs for the same network block height though.

same problem with 5x vega 64 runing hiveos and teamredminer v3.8  with 2% rejected shares in nicehash,nanopool, and all of grft mining pools.how can I set diff manually in hiveos?

[bubaba]

same problem with 5x vega 64 runing hiveos and teamredminer v3.8  with 2% rejected shares in nicehash,nanopool, and all of grft mining pools.how can I set diff manually in hiveos?

dont you add difficulty behind the wallet adress with a .(dot) ? like walletadressxyz1234.40000 for a 40000 difficulty?

[kerney666]

Hi Guys.

My "rig" running with the latest version of this miner more than 24 hours, and I have lot of rejected shares.. around 20%
I use two Asus RX580 card, GPU0 is DUAL-OC-4G with Eplida memory, GPU1 is ROG-STRIX-O8G with Hynix memory.
I tried more BIOS mod, and default BIOS and lot of settings, but the results is same... any ideas?

Here is my log:

...
[2018-11-30 17:39:09] Pool xmr-eu2.nanopool.org share accepted. (GPU0) (a:1559 r:29) (76 ms)

What is the "rejected share" exactly?

A rejected share is simply when the pool does not accept a share that you find and submit. The most common reason is that the share is submitted for an old job. CN jobs on the gpu take a while to compute, so in some cases a new job is sent out right before a job completes. Added network latency exaggerates the effect.

However, you don't have 20% rejected shares, you rather have 29/(1559+29) = 1.83% rejected shares. I'd say it's on the high side, but nothing too crazy. I don't know Nanopool's policy for accepting shares for jobs for the same network block height though.

same problem with 5x vega 64 runing hiveos and teamredminer v3.8  with 2% rejected shares in nicehash,nanopool, and all of grft mining pools.how can I set diff manually in hiveos?

Static/manual diff is between you and the pool, most common is adding "+<diff>" after the wallet, but there's no guarantee it will be accepted or honored.

I've written about this before, but Nicehash and CN GPU mining really is a bumpy ride. The job switch time for CN at Nicehash can be really short during long periods, new jobs sent out every 5-10 secs. The way you run CN on a GPU (and this goes for all miners) is that you fire away 1000-2000 hashes that are computed in parallel, but it takes 1-1.5 secs before they are all done, and they pretty much all finish at the same time. When you run against a pool that (1) send out new jobs every 5-20 secs and (2) will reject shares for most previous jobs, you will waste hash capacity one way or the other as new jobs will be received when a hash round is being computed. You can either let the hash round complete and send any shares anyway hoping the pool will accept them, or you can introduce an early abort mechanism where the work in the ongoing hash round is wasted whenever a new job is received. Both approaches will have an impact on your realized hashrate vs your theoretical miner hashrate.

For Nanopool, I'm a little surprised though. As long as there is no new network block, and a new job is only sent out due to e.g. a new ntime value in the block header or new pending txns in the network, shares for the previous job should be accepted. For a 2 min block time network, you should then expect maybe ~1% rejected shares, assuming some additional network latency as well.

[scryptr]

NOT ALL RX 550 GPUS HAVE THE SAME CHIP--

I don't know how chip-specific the code for the "L" prefix configurations are, but there are a variety of RX 550 cards that have cut-down Baffin chips:

QUOTE-- "Sapphire has introduced a new Radeon RX 550 variant with 25% more CUs.  It features a mostly disabled Polaris 21 chip with 10 CUs out of 16 CUs enabled compared to the standard RX 550 with 8 out of 10 CUs enabled.  The additional 2 CUs translates to an extra 128 Stream Processors on Sapphire's new variant.

This GPU can effectively be thought of as an RX 555 although it is not officially branded as such."

LINK-- https://linustechtips.com/main/topic/893799-sapphire-introduces-new-radeon-rx-550-with-25-more-cus-using-polaris-21-instead-of-polaris-12/

These RX 550 cards are sold alongside those with proper Lexa chips and have similar performance levels and power usage.  Not all retailers describe them with proper Compute Unit (CU) descriptions.  There are reports that the Polaris 21 RX 550 units can be unlocked to even more than 10 CUs.  A Lexa chip has 8 standard, a full Baffin chip has 16, and the RX 550 cut-down Baffin variants are sold with 10.

This is posted because TeamRedMiner (TRM) has reports of exceptionally high CNv8 hashrates with the Lexa and Baffin cards.  Will there be a forthcoming "B" (for Baffin) prefix for the configuration setting?  How chip-specific is the code?

My RX 460 Baffin cards, unlocked to 16 CUs and BIOS modded, only hash at 390 H/s on CNv8 with TRM.  The clocks are 1250/1850, and if I push the clocks higher, rejects increase and crashes occur.  The Lexa cards are reported to out-perform my unlocked Sapphire Nitro+ RX 460 cards

If there are any configuration tips, please post them.  Oh, and my rigs are mostly Linux.  Thanks, TRM is really shaping up!       --scryptr  

[ku4eto]

NOT ALL RX 550 GPUS HAVE THE SAME CHIP--

I don't know how chip-specific the code for the "L" prefix configurations are, but there are a variety of RX 550 cards that have cut-down Baffin chips:

QUOTE-- "Sapphire has introduced a new Radeon RX 550 variant with 25% more CUs.  It features a mostly disabled Polaris 21 chip with 10 CUs out of 16 CUs enabled compared to the standard RX 550 with 8 out of 10 CUs enabled.  The additional 2 CUs translates to an extra 128 Stream Processors on Sapphire's new variant.

This GPU can effectively be thought of as an RX 555 although it is not officially branded as such."

LINK-- https://linustechtips.com/main/topic/893799-sapphire-introduces-new-radeon-rx-550-with-25-more-cus-using-polaris-21-instead-of-polaris-12/

These RX 550 cards are sold alongside those with proper Lexa chips and have similar performance levels and power usage.  Not all retailers describe them with proper Compute Unit (CU) descriptions.  There are reports that the Polaris 21 RX 550 units can be unlocked to even more than 10 CUs.  A Lexa chip has 8 standard, a full Baffin chip has 16, and the RX 550 cut-down Baffin variants are sold with 10.

This is posted because TeamRedMiner (TRM) has reports of exceptionally high CNv8 hashrates with the Lexa and Baffin cards.  Will there be a forthcoming "B" (for Baffin) prefix for the configuration setting?  How chip-specific is the code?

My RX 460 Baffin cards, unlocked to 16 CUs and BIOS modded, only hash at 390 H/s on CNv8 with TRM.  The clocks are 1250/1850, and if I push the clocks higher, rejects increase and crashes occur.  The Lexa cards are reported to out-perform my unlocked Sapphire Nitro+ RX 460 cards

If there are any configuration tips, please post them.  Oh, and my rigs are mostly Linux.  Thanks, TRM is really shaping up!       --scryptr  

390H/s?

My unlocked 460 2GB was doing 525H/s on 1225/2100 on CNv7 with SGMiner-GM.

[scryptr]

NOT ALL RX 550 GPUS HAVE THE SAME CHIP--

I don't know how chip-specific the code for the "L" prefix configurations are, but there are a variety of RX 550 cards that have cut-down Baffin chips:

QUOTE-- "Sapphire has introduced a new Radeon RX 550 variant with 25% more CUs.  It features a mostly disabled Polaris 21 chip with 10 CUs out of 16 CUs enabled compared to the standard RX 550 with 8 out of 10 CUs enabled.  The additional 2 CUs translates to an extra 128 Stream Processors on Sapphire's new variant.

This GPU can effectively be thought of as an RX 555 although it is not officially branded as such."

LINK-- https://linustechtips.com/main/topic/893799-sapphire-introduces-new-radeon-rx-550-with-25-more-cus-using-polaris-21-instead-of-polaris-12/

These RX 550 cards are sold alongside those with proper Lexa chips and have similar performance levels and power usage.  Not all retailers describe them with proper Compute Unit (CU) descriptions.  There are reports that the Polaris 21 RX 550 units can be unlocked to even more than 10 CUs.  A Lexa chip has 8 standard, a full Baffin chip has 16, and the RX 550 cut-down Baffin variants are sold with 10.

This is posted because TeamRedMiner (TRM) has reports of exceptionally high CNv8 hashrates with the Lexa and Baffin cards.  Will there be a forthcoming "B" (for Baffin) prefix for the configuration setting?  How chip-specific is the code?

My RX 460 Baffin cards, unlocked to 16 CUs and BIOS modded, only hash at 390 H/s on CNv8 with TRM.  The clocks are 1250/1850, and if I push the clocks higher, rejects increase and crashes occur.  The Lexa cards are reported to out-perform my unlocked Sapphire Nitro+ RX 460 cards

If there are any configuration tips, please post them.  Oh, and my rigs are mostly Linux.  Thanks, TRM is really shaping up!       --scryptr  

390H/s?

My unlocked 460 2GB was doing 525H/s on 1225/2100 on CNv7 with SGMiner-GM.

COOL STORY BRO--

And I don't mean to be insulting, but wading through all these posts leads me to some scepticism.  Back in the day of scrypt mining (2013-2014) there would be reports of impossible clocks for R9 280X cards, clocks high enough to damage the card.

My RX 460 Baffin cards are 4GB Sapphire units, and if I push the mem clock over 1850, they are not stable.  If I could improve the TRM CNv8 hash rate with a better software configuration, I'd like to know how.  Currently my software setting is "-a cnv8 --cn_config=7-7".  It was "7+7" with TRM v0.3.7, and the same clocks.  The rejects are slightly less with TRM v0.3.8, under 1%.

Thanks for responding.       --scryptr

[ku4eto]

NOT ALL RX 550 GPUS HAVE THE SAME CHIP--

I don't know how chip-specific the code for the "L" prefix configurations are, but there are a variety of RX 550 cards that have cut-down Baffin chips:

QUOTE-- "Sapphire has introduced a new Radeon RX 550 variant with 25% more CUs.  It features a mostly disabled Polaris 21 chip with 10 CUs out of 16 CUs enabled compared to the standard RX 550 with 8 out of 10 CUs enabled.  The additional 2 CUs translates to an extra 128 Stream Processors on Sapphire's new variant.

This GPU can effectively be thought of as an RX 555 although it is not officially branded as such."

LINK-- https://linustechtips.com/main/topic/893799-sapphire-introduces-new-radeon-rx-550-with-25-more-cus-using-polaris-21-instead-of-polaris-12/

These RX 550 cards are sold alongside those with proper Lexa chips and have similar performance levels and power usage.  Not all retailers describe them with proper Compute Unit (CU) descriptions.  There are reports that the Polaris 21 RX 550 units can be unlocked to even more than 10 CUs.  A Lexa chip has 8 standard, a full Baffin chip has 16, and the RX 550 cut-down Baffin variants are sold with 10.

This is posted because TeamRedMiner (TRM) has reports of exceptionally high CNv8 hashrates with the Lexa and Baffin cards.  Will there be a forthcoming "B" (for Baffin) prefix for the configuration setting?  How chip-specific is the code?

My RX 460 Baffin cards, unlocked to 16 CUs and BIOS modded, only hash at 390 H/s on CNv8 with TRM.  The clocks are 1250/1850, and if I push the clocks higher, rejects increase and crashes occur.  The Lexa cards are reported to out-perform my unlocked Sapphire Nitro+ RX 460 cards

If there are any configuration tips, please post them.  Oh, and my rigs are mostly Linux.  Thanks, TRM is really shaping up!       --scryptr  

390H/s?

My unlocked 460 2GB was doing 525H/s on 1225/2100 on CNv7 with SGMiner-GM.

COOL STORY BRO--

And I don't mean to be insulting, but wading through all these posts leads me to some scepticism.  Back in the day of scrypt mining (2013-2014) there would be reports of impossible clocks for R9 280X cards, clocks high enough to damage the card.

My RX 460 Baffin cards are 4GB Sapphire units, and if I push the mem clock over 1850, they are not stable.  If I could improve the TRM CNv8 hash rate with a better software configuration, I'd like to know how.  Currently my software setting is "-a cnv8 --cn_config=7-7".  It was "7+7" with TRM v0.3.7, and the same clocks.  The rejects are slightly less with TRM v0.3.8, under 1%.

Thanks for responding.       --scryptr

What are the memory models of those cards? What straps are you using? How many cards and under what OS is are those?

[msTrix]

Anyone have a good example of watchdog.bat? I have a gpu that drops occasionally and I'd like to stop the miner gracefully and restart it...or handle it like SRB does.

This is where it gets a little tricky, it depends on how your rig(s) behave on a dead gpu. When I push my Vega 64 on my workstation too hard to test clocks etc I get such a hard hang that I need to cycle the PCIe root hub just to get a prompt back in order to reboot, the gpu looks ok but it's dead. Never had such a hard hang on any other setup. For my Polaris cards on the same workstation, the driver handles the reset just fine by itself and I can just do a simple restart of the miner after setting clocks. So, if I were to handle this with 100% success on this specific workstation with a single script, I would need the hard reset+reboot version.

For the simple use case of a gpu drop that the driver recovers from, I would use two bat files, one that starts the miner with your normal args, then a watchdog restart script with a delay. When the watchdog script is fired, the miner will always shut down as well.

start.bat

Code:

set GPU_MAX_ALLOC_PERCENT=100
set GPU_SINGLE_ALLOC_PERCENT=100
set GPU_MAX_HEAP_SIZE=100
set GPU_USE_SYNC_OBJECTS=1

rem Set clocks for all GPUs here

teamredminer.exe -a cnv8 -o stratum+tcp://pool.supportxmr.com:7777 -u 479c6JsyawEVAMNZU8GMmXgVPTxd1vdejR6vVpsm7z8y2AvP7C5hz2g5gfrqyffpvLPLYb2eUmmWA5yhRw5ANYyePX7SvLE -p x --watchdog_script=watchdog.bat

watchdog.bat

Code:

@echo off
echo Watchdog restarting miner in 30 secs.
timeout /T 30
start_cnv8.bat

Remember: to test your watchdog script, add " --watchdog_test" to the command line args. In the case above, that would trigger an endless cycle of restart after ~20 secs of mining.

maybe you can add the above to the 1st or 2nd post in this topic too, thanks!

[dafuzz_rsa]

@TRM Devs - Do you have a discord channel?  

[msTrix]

Is there a reference setup for RX574 ?

maybe something like (using 8+7):
1244   937   1900   900  (965 h/s, 113 W) (really stable power draw compared to the other settings which have +5 +10 W peaks)
or
1100 912    1900 900 (865 h/s, 101 W)

still figuring stuff out, but higher mem clocks dont show a gain, or cause a drop, and voltage is important, if the hash stops, increase it by 25 or 12 and try again.

As mentioned above a little higher voltage needed than for say SRB, which I was running at:
1175   812   1750   800 (833 h/s, 92 W)

Its a 'bad' card based on previous xmr-stak and SRB results, compared to the other cards I have.

All mining on CNv8, graft on grft.codpool.com

[ku4eto]

I have noticed something weird.

I have 4 cards.

1xRX570 4GB Elpida.
3xRX580 4GB, 2 of which Elpida.

The RX570 hashes absolutely the same as the RX580, despite the differences in the CUs.
Both cards are running SAME straps, SAME core clocks, SAME memory clocks.

[kerney666]

@TRM Devs - Do you have a discord channel?  

We have considered setting up a discord, but wanted to wait until we had enough activity to warrant one, it just looks boring when the last posts in all channels are old and nothing going on. Think we could revisit the idea now though.

[kerney666]

I have noticed something weird.

I have 4 cards.

1xRX570 4GB Elpida.
3xRX580 4GB, 2 of which Elpida.

The RX570 hashes absolutely the same as the RX580, despite the differences in the CUs.
Both cards are running SAME straps, SAME core clocks, SAME memory clocks.

You’re describing the very definition of a bandwidth limited process. Since they have the same memory controller and same straps and clocks, assuming you’re running 8+8, it’s not very surprising they end up with the same perf. That said, there is another aspect involved though that we will address in the future, might see a little per bump on the 580 then.

[iRonNuke]

I have noticed something weird.

I have 4 cards.

1xRX570 4GB Elpida.
3xRX580 4GB, 2 of which Elpida.

The RX570 hashes absolutely the same as the RX580, despite the differences in the CUs.
Both cards are running SAME straps, SAME core clocks, SAME memory clocks.

It think it's because CryptoNight seems depending very much at memory, not so much at core performance. Like my RX 550 8 CU gets better hashrates than my RX 560 with 14/16 CUs. All about memory performance I think. I run all of my RX 550/560/570/580s at a very low core clock (1050-1150 MHz) and gets a good hashrate even then..

[ku4eto]

I have noticed something weird.

I have 4 cards.

1xRX570 4GB Elpida.
3xRX580 4GB, 2 of which Elpida.

The RX570 hashes absolutely the same as the RX580, despite the differences in the CUs.
Both cards are running SAME straps, SAME core clocks, SAME memory clocks.

You’re describing the very definition of a bandwidth limited process. Since they have the same memory controller and same straps and clocks, assuming you’re running 8+8, it’s not very surprising they end up with the same perf. That said, there is another aspect involved though that we will address in the future, might see a little per bump on the 580 then.

I have noticed something weird.

I have 4 cards.

1xRX570 4GB Elpida.
3xRX580 4GB, 2 of which Elpida.

The RX570 hashes absolutely the same as the RX580, despite the differences in the CUs.
Both cards are running SAME straps, SAME core clocks, SAME memory clocks.

It think it's because CryptoNight seems depending very much at memory, not so much at core performance. Like my RX 550 8 CU gets better hashrates than my RX 560 with 14/16 CUs. All about memory performance I think. I run all of my RX 550/560/570/580s at a very low core clock (1050-1150 MHz) and gets a good hashrate even then..

I know what you mean, but i tested the scaling and....

Code:

Elpida 1280Mhz Core GPU 3
1850 - 1047H/s
1875 - 1050-1052H/s
1900 - 1052-1054H/s
1925 - 1052-1054H/s
1950 - 1043H/s


------

Elpida 1875Mhz Mem GPU 3

1280 - 1050-1052H/s
1250 - 1028H/s
1225 - 1010H/s
1200 - 991H/s

------
Elpida 1280Mhz Core GPU 0
1900 - 1049-1050H/s
1925 - 1052H/s
1950 - 1054H/s
1975 - 1057H/s

------

Elpida 1900Mhz Mem GPU 0

1280 - 1049-1050H/s
1250 - 1028-1029H/s
1225 - 1010-1011H/s
1200 - 991-992H/s

------

Samsung 2100Mhz Mem GPU 1

1280 - 1057H/s
1250 - 1035H/s
1225 - 1014H/s
1200 - 995H/s

------

Samsung 1280Mhz Core GPU 1

2075 - 1055H/s
2100 - 1057H/s
2125 - 1059-1061H/s
2150 - 1060-1061H/s

First is Memory clock scaling, then Core clock scaling.

GPU 0/3 -> 570/580 Elpida.
GPU 1 -> 580 Samsung.
Seems weird, for 75Mhz Memclock increase, to get only about 10Hs. Usually, it should be around 30H/s for ~75Mhz increase (at least on XMR-Stak).


EDIT: For clarification, are HWs actually considered Bad shares, that failed CPU check (meaning, GPU worked on them, and before submitting, it failed) ?