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

[Syndicate2019]

Hi,

this is a great miner for us in windows10 LTSB for our RX550's,  Baffin core unlocked to12 CU, 2GB ram, one click  mod timing strap. We get 500ish hash rate at 1050core 1820mem 800mv drawing less than 50w.

But in any combo of ubuntu, 16.04 or 18.40, withamd driver 17.50 to 18.50, they are hashing not even near to 500hs but 400.. The best has been 3.4kh on a B250 mobo 8gpu rig, mining to nanopool or f2pool the same.

Any thing thing special we can do to make it close to win10 LTSB amd drive 18.6.1 in ubuntu?

Currently we do:

1. hard code 1050/1800 in bios(hiveos is buggy when overlocking baffin),
2. fresh installed server version
3. sudo apt-get update, them tar amd drive and amdgpu-pro-install compute mode or opencl=pay, legacy
4 reboot and run  ./teamredminer -a cnr -o xmr.f2pool.com:13531 -u wallet.paymentid --cn_config 3+3
5 poor 400ish per gpu

is there anything we have missed? or baffins simply does not work well in ubuntu?

thank you for the great miner again. you are our simple best choice since the lya2z days.

[1714652986]

1714652986

[1714652986]

1714652986

[1714652986]

1714652986

[Mashy81]

Hi there,

I have a rig with mixed 480 and 580. I used command like:

teamredminer.exe -a cnr -o stratum+tcp://pool.supportxmr.com:7777 -u 84PDXS6PngdBh2XUd28jbN3Sb69RXPq7gdCNVukcrFCj1v6jgb13uEpHrzf6DF9cDjKCToaS842gLx8 sgF1jNCNGfuFgi -p amd:cryptocoins@outlook.com
-d 0,1,2,3,4,5 --cn_config 8+8,8+8,8+8,8+8,8+8,8+8


Here is what I got:

         Team Red Miner version 0.4.2
[2019-03-17 16:37:13] Auto-detected AMD OpenCL platform 0
[2019-03-17 16:37:20] Initializing GPU 0.
[2019-03-17 16:37:20] Watchdog thread starting.
[2019-03-17 16:37:20] Pool pool.supportxmr.com connecting to address 104.140.201.62.
[2019-03-17 16:37:20] Pool pool.supportxmr.com successfully connected to address 104.140.201.62.
[2019-03-17 16:37:20] Pool pool.supportxmr.com login succeeded.(76 ms)
[2019-03-17 16:37:20] Pool pool.supportxmr.com received new job. (job_id: cnLOlcrewGdcVf1XzQRbdhjwp1Vb)
[2019-03-17 16:37:20] Pool pool.supportxmr.com set difficulty to 40000
[2019-03-17 16:37:21] Dev pool connected and ready.
[2019-03-17 16:37:25] Pool pool.supportxmr.com received new job. (job_id: XIB96CLjgQdVKYBbNUaRktOh8rcO)
[2019-03-17 16:37:25] Pool pool.supportxmr.com set difficulty to 68571
[2019-03-17 16:37:50] Stats Uptime: 0 days, 00:00:32
[2019-03-17 16:37:50] GPU 0 [30C, fan 55%] cnr:   0.0 h/s, avg   0.0 h/s, pool   0.0 h/s a:0 r:0 hw:0
[2019-03-17 16:37:50] GPU 1 [28C, fan 55%] cnr:   0.0 h/s, avg   0.0 h/s, pool   0.0 h/s a:0 r:0 hw:0
[2019-03-17 16:37:50] GPU 2 [29C, fan 55%] cnr:   0.0 h/s, avg   0.0 h/s, pool   0.0 h/s a:0 r:0 hw:0
[2019-03-17 16:37:50] GPU 3 [29C, fan 55%] cnr:   0.0 h/s, avg   0.0 h/s, pool   0.0 h/s a:0 r:0 hw:0
[2019-03-17 16:37:50] GPU 4 [28C, fan 55%] cnr:   0.0 h/s, avg   0.0 h/s, pool   0.0 h/s a:0 r:0 hw:0
[2019-03-17 16:37:50] GPU 5 [23C, fan 55%] cnr:   0.0 h/s, avg   0.0 h/s, pool   0.0 h/s a:0 r:0 hw:0
[2019-03-17 16:37:50] Total                cnr:   0.0 h/s, avg   0.0 h/s, pool   0.0 h/s a:0 r:0 hw:0
[2019-03-17 16:38:20] Stats Uptime: 0 days, 00:01:02
[2019-03-17 16:38:20] GPU 0 [29C, fan 55%] cnr:   0.0 h/s, avg   0.0 h/s, pool   0.0 h/s a:0 r:0 hw:0
[2019-03-17 16:38:20] GPU 1 [27C, fan 55%] cnr:   0.0 h/s, avg   0.0 h/s, pool   0.0 h/s a:0 r:0 hw:0
[2019-03-17 16:38:20] GPU 2 [29C, fan 55%] cnr:   0.0 h/s, avg   0.0 h/s, pool   0.0 h/s a:0 r:0 hw:0
[2019-03-17 16:38:20] GPU 3 [28C, fan 55%] cnr:   0.0 h/s, avg   0.0 h/s, pool   0.0 h/s a:0 r:0 hw:0
[2019-03-17 16:38:20] GPU 4 [28C, fan 55%] cnr:   0.0 h/s, avg   0.0 h/s, pool   0.0 h/s a:0 r:0 hw:0
[2019-03-17 16:38:20] GPU 5 [23C, fan 55%] cnr:   0.0 h/s, avg   0.0 h/s, pool   0.0 h/s a:0 r:0 hw:0
[2019-03-17 16:38:20] Total                cnr:   0.0 h/s, avg   0.0 h/s, pool   0.0 h/s a:0 r:0 hw:0
[2019-03-17 16:38:25] Pool pool.supportxmr.com received new job. (job_id: i5dMQvSKsNVfeMp9FbvfyScUpeu5)
[2019-03-17 16:38:25] Pool pool.supportxmr.com set difficulty to 45714
[2019-03-17 16:38:50] Stats Uptime: 0 days, 00:01:32
[2019-03-17 16:38:50] GPU 0 [29C, fan 55%] cnr:   0.0 h/s, avg   0.0 h/s, pool   0.0 h/s a:0 r:0 hw:0
[2019-03-17 16:38:50] GPU 1 [27C, fan 55%] cnr:   0.0 h/s, avg   0.0 h/s, pool   0.0 h/s a:0 r:0 hw:0
[2019-03-17 16:38:50] GPU 2 [29C, fan 55%] cnr:   0.0 h/s, avg   0.0 h/s, pool   0.0 h/s a:0 r:0 hw:0
[2019-03-17 16:38:50] GPU 3 [28C, fan 55%] cnr:   0.0 h/s, avg   0.0 h/s, pool   0.0 h/s a:0 r:0 hw:0
[2019-03-17 16:38:50] GPU 4 [27C, fan 55%] cnr:   0.0 h/s, avg   0.0 h/s, pool   0.0 h/s a:0 r:0 hw:0
[2019-03-17 16:38:50] GPU 5 [23C, fan 55%] cnr:   0.0 h/s, avg   0.0 h/s, pool   0.0 h/s a:0 r:0 hw:0
[2019-03-17 16:38:50] Total                cnr:   0.0 h/s, avg   0.0 h/s, pool   0.0 h/s a:0 r:0 hw:0
[2019-03-17 16:39:10] GPU 0: detected DEAD (34:00.0), no restart script configured, will continue mining.
[2019-03-17 16:39:10] Please use command line argument --watchdog_script to handle dead GPUs.
[2019-03-17 16:39:10] GPU 1: detected DEAD (30:00.0), no restart script configured, will continue mining.
[2019-03-17 16:39:10] Please use command line argument --watchdog_script to handle dead GPUs.
[2019-03-17 16:39:10] GPU 2: detected DEAD (31:00.0), no restart script configured, will continue mining.
[2019-03-17 16:39:10] Please use command line argument --watchdog_script to handle dead GPUs.
[2019-03-17 16:39:10] GPU 3: detected DEAD (38:00.0), no restart script configured, will continue mining.
[2019-03-17 16:39:10] Please use command line argument --watchdog_script to handle dead GPUs.
[2019-03-17 16:39:10] GPU 4: detected DEAD (01:00.0), no restart script configured, will continue mining.
[2019-03-17 16:39:10] Please use command line argument --watchdog_script to handle dead GPUs.
[2019-03-17 16:39:10] GPU 5: detected DEAD (35:00.0), no restart script configured, will continue mining.
[2019-03-17 16:39:10] Please use command line argument --watchdog_script to handle dead GPUs.
[2019-03-17 16:39:20] Stats Uptime: 0 days, 00:02:02
[2019-03-17 16:39:20] GPU 0 [29C, fan 55%] cnr:   0.0 h/s, avg   0.0 h/s, pool   0.0 h/s a:0 r:0 hw:0
[2019-03-17 16:39:20] GPU 1 [27C, fan 55%] cnr:   0.0 h/s, avg   0.0 h/s, pool   0.0 h/s a:0 r:0 hw:0
[2019-03-17 16:39:20] GPU 0: detected DEAD (34:00.0), no restart script configured, will continue mining.
[2019-03-17 16:39:20] Please use command line argument --watchdog_script to handle dead GPUs.
[2019-03-17 16:39:20] GPU 1: detected DEAD (30:00.0), no restart script configured, will continue mining.
[2019-03-17 16:39:20] Please use command line argument --watchdog_script to handle dead GPUs.
[2019-03-17 16:39:20] GPU 2: detected DEAD (31:00.0), no restart script configured, will continue mining.
[2019-03-17 16:39:20] Please use command line argument --watchdog_script to handle dead GPUs.
[2019-03-17 16:39:20] GPU 3: detected DEAD (38:00.0), no restart script configured, will continue mining.
[2019-03-17 16:39:20] Please use command line argument --watchdog_script to handle dead GPUs.
[2019-03-17 16:39:20] GPU 4: detected DEAD (01:00.0), no restart script configured, will continue mining.
[2019-03-17 16:39:20] Please use command line argument --watchdog_script to handle dead GPUs.
[2019-03-17 16:39:20] GPU 5: detected DEAD (35:00.0), no restart script configured, will continue mining.
[2019-03-17 16:39:20] Please use command line argument --watchdog_script to handle dead GPUs.

Have you read any other posts??
If you had you would realise 8+8 is to high for those cards. Also it always pays to try a few different settings yourself some times. Try 8+7 or  7+7 or 6+6 ...........

[Mashy81]

Hi,

this is a great miner for us in windows10 LTSB for our RX550's,  Baffin core unlocked to12 CU, 2GB ram, one click  mod timing strap. We get 500ish hash rate at 1050core 1820mem 800mv drawing less than 50w.

But in any combo of ubuntu, 16.04 or 18.40, withamd driver 17.50 to 18.50, they are hashing not even near to 500hs but 400.. The best has been 3.4kh on a B250 mobo 8gpu rig, mining to nanopool or f2pool the same.

Any thing thing special we can do to make it close to win10 LTSB amd drive 18.6.1 in ubuntu?

Currently we do:

1. hard code 1050/1800 in bios(hiveos is buggy when overlocking baffin),
2. fresh installed server version
3. sudo apt-get update, them tar amd drive and amdgpu-pro-install compute mode or opencl=pay, legacy
4 reboot and run  ./teamredminer -a cnr -o xmr.f2pool.com:13531 -u wallet.paymentid --cn_config 3+3
5 poor 400ish per gpu

is there anything we have missed? or baffins simply does not work well in ubuntu?

thank you for the great miner again. you are our simple best choice since the lya2z days.

Try  L4+3 or L3+3.
I get 540hs on W10 with 2gb 550's

[kerney666]

Hi there,

I have a rig with mixed 480 and 580. I used command like:

teamredminer.exe -a cnr -o stratum+tcp://pool.supportxmr.com:7777 -u 84PDXS6PngdBh2XUd28jbN3Sb69RXPq7gdCNVukcrFCj1v6jgb13uEpHrzf6DF9cDjKCToaS842gLx8 sgF1jNCNGfuFgi -p amd:cryptocoins@outlook.com
-d 0,1,2,3,4,5 --cn_config 8+8,8+8,8+8,8+8,8+8,8+8


Here is what I got:

         Team Red Miner version 0.4.2
[2019-03-17 16:37:13] Auto-detected AMD OpenCL platform 0
[2019-03-17 16:37:20] Initializing GPU 0.
[2019-03-17 16:37:20] Watchdog thread starting.
...
[2019-03-17 16:39:20] GPU 5: detected DEAD (35:00.0), no restart script configured, will continue mining.
[2019-03-17 16:39:20] Please use command line argument --watchdog_script to handle dead GPUs.

Have you read any other posts??
If you had you would realise 8+8 is to high for those cards. Also it always pays to try a few different settings yourself some times. Try 8+7 or  7+7 or 6+6 ...........

Yes, init is failing. Another potential issue (that we should document better) is concurrent cpu mining. If you're cpu mining while starting the miner, please stop cpu mining and start the miner. Once the miner is running, you can safely start parallel cpu mining again, it's just very sensitive during startup. This is an unfortunate side-effect of having a different initialization process than other miners.

[kerney666]

Hi,

this is a great miner for us in windows10 LTSB for our RX550's,  Baffin core unlocked to12 CU, 2GB ram, one click  mod timing strap. We get 500ish hash rate at 1050core 1820mem 800mv drawing less than 50w.

But in any combo of ubuntu, 16.04 or 18.40, withamd driver 17.50 to 18.50, they are hashing not even near to 500hs but 400.. The best has been 3.4kh on a B250 mobo 8gpu rig, mining to nanopool or f2pool the same.

Any thing thing special we can do to make it close to win10 LTSB amd drive 18.6.1 in ubuntu?

Currently we do:

1. hard code 1050/1800 in bios(hiveos is buggy when overlocking baffin),
2. fresh installed server version
3. sudo apt-get update, them tar amd drive and amdgpu-pro-install compute mode or opencl=pay, legacy
4 reboot and run  ./teamredminer -a cnr -o xmr.f2pool.com:13531 -u wallet.paymentid --cn_config 3+3
5 poor 400ish per gpu

is there anything we have missed? or baffins simply does not work well in ubuntu?

thank you for the great miner again. you are our simple best choice since the lya2z days.

Try  L4+3 or L3+3.
I get 540hs on W10 with 2gb 550's

Yep Mashy81 is spot on, always try the "L" prefix for Baffins and Lexa Pros, then a few different configs as well. We do know of linux users who are nailing 500-550 h/s on various 550s, although the added (and variable) compute pressure in cn/r vs cnv8 can sometimes be problematic for a stable hashrate.

[oxzhor]

What is the correct -a for cnv8_dbl?

teamredminer.exe -a cnv8_dbl not work at windows it close the window at startup.

Can you provide your full cmd line? If you have the miner working fine with cnr or cnv8, you should be able to set "cnv8_dbl" as algo and change the pool/wallet/password, and things should work.

Here we go:

teamredminer.exe -a cnv8_dbl -o stratum+tcp://eu.XCA.cryptopool.space:7777 -u XCA... -p xxx --cn_config 16+14,16+14,16+14,16+14 --watchdog_script=watchdog.bat

[kerney666]

@todxx @kerney666 - i'm struggling w/ some stability issues.  linux/0.4.1/cnr/15+15 on an 8x64 rig - can run fine for 1hr or 6 hrs, but seems to always fall over eventually.  I'm definitely at oc/uv thresholds, but where normally I could isolate crashes to specific cards and adjust settings, in this case it's a different card every time.  It's not temps (all under 45c) or hardware errors (none reported by miner or syslog.)  I'm wondering if it's maybe following network hiccups or dev fee switching?  Tho i can't find any messaging in the logs - any way we can get network/dev fee notices in the logs?  I'm also seeing init discrepancies - tho not as bad as 0.4.0 - but sometimes random cards underperform by 10-15h/s run-to-run (was more like 40-50 on 0.4.0), so possibly something to do w/ that?

Also, tried 0.4.2, and it falls over w/in seconds for the same settings - seems much harsher on init for some reason.

Hey pbfarmer, what's the current status here? It feels like we're really at the edge of a cliff here, the changes between 0.41 and 0.4.2 are so tiny. In 0.4.2 we drive the jobs in a more simple, straightforward way, but it should really have zero effect on stability.

There is no dev fee switching in the miner, we mine user + dev concurrently, so there is no interruption, variable pressure or potential hick-up from that perspective. CN/r will by design have a variable compute pressure, for some block heights you will be unfortunate and get a huge amount of multiplications, the next block you just get a few muls and a bunch of simple xors and subs instead. So maaaaybe the worst case scenario here could be problematic if you're tuned to a more average load.

There is a little clue in your 0.4.0 vs 0.4.1 description though, we did change a initial delay in 0.4.1. CN mining on gpu is all about keeping a certain delay between the two threads to get a proper overlap. If the threads gravitate and the delay/offset creeps too close to zero, you will lose a little of your hashrate. If they fully coincide, it will be very visible. This hasn't really been a problem for us before, but for some reason CN/r is a little bitchy.

One interesting thing related to this is that if the threads do coincide, the power draw profile for that gpu will change. There will be longer full throttle periods at the beginning and end of each cycle, and longer periods in-between with a much lower power draw. So, this is a wild guess, but maybe this is what happens by random chance over time for one of the gpus. If you do have logs, it could potentially be visible that the hashrate for the gpu that dies is decreasing the print(s) before it dies.

It's still very surprising that 0.4.2 dies within a few seconds, wow. Need to ponder this a bit more, then maybe give you a few test builds with additional logging.

[kerney666]

What is the correct -a for cnv8_dbl?

teamredminer.exe -a cnv8_dbl not work at windows it close the window at startup.

Can you provide your full cmd line? If you have the miner working fine with cnr or cnv8, you should be able to set "cnv8_dbl" as algo and change the pool/wallet/password, and things should work.

Here we go:

teamredminer.exe -a cnv8_dbl -o stratum+tcp://eu.XCA.cryptopool.space:7777 -u XCA... -p xxx --cn_config 16+14,16+14,16+14,16+14 --watchdog_script=watchdog.bat

Are you sure you're running the latest 0.4.2 version? The thing is your cmd line works fine for me, only thing I replaced was the wallet.

If you're running this from a .bat file and the window closes so you don't see any output, can you add a line with "pause" at the end of the .bat, then paste the output here?

[oxzhor]

What is the correct -a for cnv8_dbl?

teamredminer.exe -a cnv8_dbl not work at windows it close the window at startup.

Can you provide your full cmd line? If you have the miner working fine with cnr or cnv8, you should be able to set "cnv8_dbl" as algo and change the pool/wallet/password, and things should work.

Here we go:

teamredminer.exe -a cnv8_dbl -o stratum+tcp://eu.XCA.cryptopool.space:7777 -u XCA... -p xxx --cn_config 16+14,16+14,16+14,16+14 --watchdog_script=watchdog.bat

Are you sure you're running the latest 0.4.2 version? The thing is your cmd line works fine for me, only thing I replaced was the wallet.

If you're running this from a .bat file and the window closes so you don't see any output, can you add a line with "pause" at the end of the .bat, then paste the output here?

Erm :S sorry i need an coffee i was test it 0.4.1 solved now at 0.4.2.
Sorry for any inconvenience this may caused.

[pbfarmer]

@todxx @kerney666 - i'm struggling w/ some stability issues.  linux/0.4.1/cnr/15+15 on an 8x64 rig - can run fine for 1hr or 6 hrs, but seems to always fall over eventually.  I'm definitely at oc/uv thresholds, but where normally I could isolate crashes to specific cards and adjust settings, in this case it's a different card every time.  It's not temps (all under 45c) or hardware errors (none reported by miner or syslog.)  I'm wondering if it's maybe following network hiccups or dev fee switching?  Tho i can't find any messaging in the logs - any way we can get network/dev fee notices in the logs?  I'm also seeing init discrepancies - tho not as bad as 0.4.0 - but sometimes random cards underperform by 10-15h/s run-to-run (was more like 40-50 on 0.4.0), so possibly something to do w/ that?

Also, tried 0.4.2, and it falls over w/in seconds for the same settings - seems much harsher on init for some reason.

Hey pbfarmer, what's the current status here? It feels like we're really at the edge of a cliff here, the changes between 0.41 and 0.4.2 are so tiny. In 0.4.2 we drive the jobs in a more simple, straightforward way, but it should really have zero effect on stability.

There is no dev fee switching in the miner, we mine user + dev concurrently, so there is no interruption, variable pressure or potential hick-up from that perspective. CN/r will by design have a variable compute pressure, for some block heights you will be unfortunate and get a huge amount of multiplications, the next block you just get a few muls and a bunch of simple xors and subs instead. So maaaaybe the worst case scenario here could be problematic if you're tuned to a more average load.

There is a little clue in your 0.4.0 vs 0.4.1 description though, we did change a initial delay in 0.4.1. CN mining on gpu is all about keeping a certain delay between the two threads to get a proper overlap. If the threads gravitate and the delay/offset creeps too close to zero, you will lose a little of your hashrate. If they fully coincide, it will be very visible. This hasn't really been a problem for us before, but for some reason CN/r is a little bitchy.

One interesting thing related to this is that if the threads do coincide, the power draw profile for that gpu will change. There will be longer full throttle periods at the beginning and end of each cycle, and longer periods in-between with a much lower power draw. So, this is a wild guess, but maybe this is what happens by random chance over time for one of the gpus. If you do have logs, it could potentially be visible that the hashrate for the gpu that dies is decreasing the print(s) before it dies.

It's still very surprising that 0.4.2 dies within a few seconds, wow. Need to ponder this a bit more, then maybe give you a few test builds with additional logging.

I've been peeling off cards one by one as they die - down 3 right now, but on a ~12hr run so far, which is promising.

Thanks for all the insights - this is helpful... Any sense of the distribution/std. dev of mathematical difficulty (as related to compute pressure) between blocks?  I.e. would a few blocks run be highly indicative of compute pressure, or do we need to look at much larger windows (hence the failures after 5-6 hours)?

Re the thread overlap - I wonder if some sort of occasional thread re-sync mechanism may avoid any concern over drift? Regardless, I can watch the logs closely to see if something happens to h/r near the time of crash/hang.  That being said, the h/r discrepancies I mentioned are visible immediately from launch, so it sounds like there can be situations where the threads aren't ideally offset even following init.  For instance, w/ all 8 cards online, I usually saw ~16.82, but sometimes as high as 16.87, or as low as 16.76 at startup.

As for 0.4.2, lemme know any tests you need.  I also saw this behavior on another rig, and mentioned it in a reply to another post here.  In that case, the miner locked up right after platform detection (I assume trying to init the first GPU,) though 0.4.1 had been fine on the same settings.  I bumped the cclock down or voltage up (can't remember which) and its fine now, so I will try again on this rig once I get a sense for which GPUs are being difficult.  Could is just be that 0.4.2 is somehow finding/testing the threshold earlier?

EDIT: of course, immediately after i hit submit, rig goes down again...  No indication of h/r loss in logs leading up to hang.

[MingMining]

Hi there,

I have a rig with mixed 480 and 580. I used command like:

teamredminer.exe -a cnr -o stratum+tcp://pool.supportxmr.com:7777 -u 84PDXS6PngdBh2XUd28jbN3Sb69RXPq7gdCNVukcrFCj1v6jgb13uEpHrzf6DF9cDjKCToaS842gLx8 sgF1jNCNGfuFgi -p amd:cryptocoins@outlook.com
-d 0,1,2,3,4,5 --cn_config 8+8,8+8,8+8,8+8,8+8,8+8


Here is what I got:

         Team Red Miner version 0.4.2
[2019-03-17 16:37:13] Auto-detected AMD OpenCL platform 0
[2019-03-17 16:37:20] Initializing GPU 0.
[2019-03-17 16:37:20] Watchdog thread starting.
...
[2019-03-17 16:39:20] GPU 5: detected DEAD (35:00.0), no restart script configured, will continue mining.
[2019-03-17 16:39:20] Please use command line argument --watchdog_script to handle dead GPUs.

Have you read any other posts??
If you had you would realise 8+8 is to high for those cards. Also it always pays to try a few different settings yourself some times. Try 8+7 or  7+7 or 6+6 ...........

Yes, init is failing. Another potential issue (that we should document better) is concurrent cpu mining. If you're cpu mining while starting the miner, please stop cpu mining and start the miner. Once the miner is running, you can safely start parallel cpu mining again, it's just very sensitive during startup. This is an unfortunate side-effect of having a different initialization process than other miners.

Indeed that is the issue. I stopped the cpu mining and run the start again and everything works fine now. Thanks for the information and please document this.

[jazz1984]

Hi what driver is best for win7 RX550/2 for cryptonight?

[tipo70]

A message "pool.supportxmr.com has stopped responding (64 rpcs outstanding)" crashes on one of the farms. Miner writes that the program will be closed.

[kerney666]

Hi what driver is best for win7 RX550/2 for cryptonight?

I'll have to hope that someone in the general audience can give you a hint here, we have done zero testing on win 7 unfortunately.

[kerney666]

A message "pool.supportxmr.com has stopped responding (64 rpcs outstanding)" crashes on one of the farms. Miner writes that the program will be closed.

Well, it's what the message says, we have sent 64 messages over the network without a single reply so there's something iffy with the network connection to the pool for that rig. After 64 rpcs with no reply our buffers are full and we give up, although a more graceful restart of the network connection is what I'd hoped would happen rather than a crash . Will make a note and see if we can find a bug.

[mindstorms54]

Would you please add the stale rate count?
I lived in a country surrounded by sea in all directions
It's really hard for me too pick a decent server without the stale rate info
Really needs it
thanks

[jazz1984]

Hi what driver is best for win7 RX550/2 for cryptonight?

I'll have to hope that someone in the general audience can give you a hint here, we have done zero testing on win 7 unfortunately.

So it must be win 10 or linux for better result? For linux, as i understand, it must be rocm or gpupro, and for win 10 what driver best?

[UnclWish]

Hi what driver is best for win7 RX550/2 for cryptonight?

I'll have to hope that someone in the general audience can give you a hint here, we have done zero testing on win 7 unfortunately.

So it must be win 10 or linux for better result? For linux, as i understand, it must be rocm or gpupro, and for win 10 what driver best?

Try latest 19.3.2. I use it for RX 580. Speed is good.

[kerney666]

Would you please add the stale rate count?
I lived in a country surrounded by sea in all directions
It's really hard for me too pick a decent server without the stale rate info
Really needs it
thanks

If we're talking about CN, and you have cpu verification enabled (it's on by default), you have the rejected share count already in the printed stats. When shares are verified on cpu before being submitted, a stale share is pretty much the only reason for a pool reject.

Moreover, the round-trip time for getting a share response from the pool is printed for each share. If you're testing different servers, check the ms number reported for each share.

[kerney666]

Hi what driver is best for win7 RX550/2 for cryptonight?

I'll have to hope that someone in the general audience can give you a hint here, we have done zero testing on win 7 unfortunately.

So it must be win 10 or linux for better result? For linux, as i understand, it must be rocm or gpupro, and for win 10 what driver best?

I believe there are people using the miner on win 7, but I do not know if there's any driver that provides the same perf as the more battle-tested drivers under win 10 and linux.

For win 10, I believe most drivers between 18.5.1 - 19.3.2 will work just fine. 18.6.1 is the one I've used the most, but lately I've been on newer drivers (19.2.2 - 19.3.2) due to having a Radeon VII in my test rig.

For linux, amdgpu-pro is what we support for CN, we don't have rocm support for CN right now. I believe any amdgpu-pro version >= 18.30 will enable windows-class hash rates, but I'm guessing 18.50 is what most people are using now.