Topic: [ANN] sgminer v5 - optimized X11/X13/NeoScrypt/Lyra2RE/etc. kernel-switch miner - page 231. (Read 877859 times)

guys,
how do you enable the auto algo switching mode ?
if i launch the miner it goes to the first server in the list
(i've got 2: on X13  and one X11 on  trade my bit)
it's not choosen on the profitability but in the order in the .conf

Also, the overheat issue is back whenever you encounter this crash too.  If you soft-restart your rig, the next time you boot up the miner, all the temps are on overheat and it ratchets your fans up to 100%.

Something's being overlooked.

Interesting, I've been the one encountering DEAD cards and mrbrdo thinks it's just my particular configuration.

It's not like I could stress enough that something is inherently wrong with the miner and I experience the SICK -> DEAD issue too.  But they simply won't extend the timer, or address it.

Any bounty for bug free multi-algo miner?

Hi. Much as we'd like to, we (NiceHash) can't do much to address various sgminer_v5 issues. NiceHash auto-switching service is running very stable, however, there are still some issues, need to be addressed regarding the sgminer_v5 itself. As I mentioned in the first post, we've sponsored the development of new sgminer, but haven't been involved in the development itself. sgminer_v5 is still in beta and mrbrdo, the lead developer of the sgminer kernel switching functionality obviously underestimated the difficulty of the kernel switching implementation. sgminer v5 with kernel switching has been tested in our labs and is working fine with basic (no overclocking or special tuning) GPU configuration (also, many users are successfully using this functionality on our service for quite some time now). However, AMD GPU world is extremely diverse and there are many combinations and configurations of various GPU+OS+drivers+overclocking+tuning that obviously raises issues and instability with kernel switching functionality as reported by the community and beta testers. I'm sure that mrbrdo and other sgminer developers will address all these issues and will have a stable working solution for various GPU+OS+drivers+overclocking+tuning combination in the near future. The community involvement is very important with reports on issues and help with testing - it has been like this from the early development of cgminer (I'm sure some of you remembers issues when fist Bitcoin ASICs arrived, etc.) and all later forks and versions. Therefore I ask you for help with reporting issues to https://github.com/sgminer-dev/sgminer/issues. The most useful reports are the one with 100% repeatable scenario and with the debug log files "sgminer ... -D 2>>sgminer.log" attached to issue reports.

One of the currently most problematic issue is the one with pool-gpu-engine and pool-gpu-memclock not being evaluated correctly when switching algorithms (https://github.com/sgminer-dev/sgminer/issues/265). This might cause freezes, lower hashrate, died GPU's, etc. Therefore I ask you to test the auto-switching functionality without setting different engine and mem clock per pool/algo - use the same engine and mem speed for all algos and use explicit low-high specification to disable engine/mem throttling. And start by using default/stock engine/settings! Also, make sure you specify low enough thread-concurrency for scrypt-N - test with various low enough settings if you're getting "-4 enqueueing error" and make sure you're using at least "worksize" : "256" for scrypt-N if you're seeing issues with scrypt-N (for now, worksize can't be configured in a per-pool fashion). Last, but not least, make sure you're using the latest version from https://nicehash.com/software/#sgminer. Here is an example of 100% working configuration for a rig with 5x Radeon R9 290 on Linux where switching between all algorithms with all combinations works 100% correct without any GPU issues and with decent hashrate

scrypt: 840 khs
scryptN: 420 khs
X11: 3.15 Mhs
X13: 2.25 Mhs
keccak: 390 Mhs


Edit: it looks like the "thread was not cancelled in 60 seconds after restart_mining_threads" is another issue that is platform/os/drivers/dependent as it mainly tend to show on Windows; in our testing on Linux rigs we never encountered this issue. It is discussed here: https://github.com/sgminer-dev/sgminer/issues/246. The solution is to not use "pool-gpu-threads" and use only "gpu-threads" in the global config part.

Regarding the dilemma on weather to use or not to use multi-switching functionality: well, as you've observed in the last few weeks there are truly big fluctuations in profitability for various algorithms and it looks like it's going to be this way in the near future as well. First there has only been Bitcoin - almost no work for miner - run and forget, then came Litecoin - more tuning for Scrypt needed; then came X-altcoins - lots of work for miner to keep up with different coin profitability - solved by multipools; and now there are X-algorithms - lots of work for miner to keep up with different algorithm profitability - to be solved by multi-algo-auto-switching. Said that - if you like to constantly watch algorithm profitability, then you can switch miners manually, but if you just want to run your miners and let them get best profit four you - well then you'll have to go with multi-algo-auto-switching. We're not quite there yet, but will be soon.

thats not the error i get, i never get -4 enqueueing error

mine just go DEAD,  and the pc freezes but only when switching algos  and only when X11/X13 to Scrypt-N scrypt to scrypt-n is fine x11-to x13 is fine scrypt n by itself fine

its weird

They know -- https://github.com/sgminer-dev/sgminer/issues/246

TL;DR - "But back to the point, I spent some time looking at what could be causing this weird bug with scrypt kernels, but I have no idea at all yet :/"

yea thats what im doing right now, but at any time it can go the other way... my power is free so i dont care about heat or ower at the moment i just have my rigs mining scrypt/scrypt-n at the moment ... id just like to a) make sure the devs know its a reproduceable problem and b) that it needs to be corrected soon i have a workaround at the moment but sometime it will become more of a headache

Pretty much just don't use it for that, right now.  If you are living in an area where you can mine scrypt-n without it being unbearably hot, then I would just do so for a few hours a day with another mining program right now, since it's been the dominant profitable algorithm on nicehash now for 3 days straight.  You're not missing anything with these shitty rental rates and profitability right now amongst x11/x13.

To the dev: what is being done to fix the crashing/hanging of the computer when switching from X11/x13 back to scrypt-n ?

this is a huge issue

im using CGWatcher perfectly fine, i did have a problem when i wasnt using the "Arguments" textbox, so i had to fill that in as well and now its 100% running fine ...


Under Settings Tab, this is what i have configured ...

Miner:   C:\Coin mining\sgminer-win32\sgminer.exe

Config File:    C:\Coin mining\sgminer-win32\scrypt.conf

Arguments:     "--config=C:\Coin mining\sgminer-win32\scrypt.conf" 2>log.txt

+1000 on that

When you see cuda miner... don't we have to sell our AMD boards if miner doesn't improve significantly ? :p

Still no fix for CGWatcher?

Yup i'm with you. Ill go back to standard mining until NiceHash Guys start posting what they are doing to address these issues

I'd be interested to see how they account for difference in power usage as well.

I'm starting to wonder about what determines whether or not an algo is more profitable.  Nicehash says 'volume' has to be big enough to warrant a switch, yet I'm looking at Scrypt-N, and it's going for twice as much as Scrypt very clearly.  Would it be better to switch to Scrypt with a higher volume, or remain on N-Scrypt and wait for slower sales at higher prices?

Edit:  Nevermind, I see.

Should be safe to say this miner can't effectively handle scrypt.  And that's ok!

Yep, it's undoubtedly broke.  I'm going to stick to 1 algorithm since it seems Scrypt and N-Scrypt are neck-to-neck right now.

Scratch that, just switched from scrypt-n to scrypt and my 280x rig took a dive.