Topic: [ANN] TeamRedMiner v0.10.10 - Ironfish/Kaspa/ZIL/Kawpow/Etchash and More - page 99. (Read 211877 times)

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

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?

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

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.

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.

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.

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

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.

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.

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.

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?

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.

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

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.

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.

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

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.

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:[email protected]
-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.

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.