I cancelled order #19987 ~15 minutes ago. Unspent BTC was not returned, although the fee was. Can someone from nicehash please look into it?
Please send me your account name and order # to PM. |
|
|
|
suchmoon, today we introduced another advanced feature for GPU miners @NiceHash - fine tuning with custom speed factors and daily costs ... you can now set custom hashing rate factors and even your electricity power consumption as well ... visit https://www.nicehash.com/multialgo/#finetuning and play around ... if you have some stable linux rig with sgminer_v5 with tested stable multi-algo switching you can include it in your charts. |
|
|
|
Today we introduced another advanced feature for GPU miners - Fine tuning with custom speed factors and daily costs. You can now set custom hashing rate factors and even your electricity power consumption as well! This will make sure your miner mines on absolutely most profitable algorithm. You can also configure your miner, for example, to only switch between X11 and X13 (whichever is more profitable) even if globally some other algorithm is more profitable. Visit https://www.nicehash.com/multialgo/#finetuning and play around  I'm sure this is one very nice tool for GPU users to play with! p.s.: this is why you may have notice several disconnects today while we were deploying this new features |
|
|
|
Today we introduced another advanced feature for GPU miners - Fine tuning with custom speed factors and daily costs. You can now set custom hashing rate factors and even your electricity power consumption as well! This will make sure your miner mines on absolutely most profitable algorithm. You can also configure your miner, for example, to only switch between X11 and X13 (whichever is more profitable) even if globally some other algorithm is more profitable. Visit https://www.nicehash.com/multialgo/#finetuning and play around I'm sure this is one very nice tool for GPU users to play with! |
|
|
|
Today we introduced another advanced feature for GPU miners - Fine tuning with custom speed factors and daily costs. You can now set custom hashing rate factors and even your electricity power consumption as well! This will make sure your miner mines on absolutely most profitable algorithm. You can also configure your miner, for example, to only switch between X11 and X13 (whichever is more profitable) even if globally some other algorithm is more profitable. Visit https://www.nicehash.com/multialgo/#finetuning and play around I'm sure this is one very nice tool for GPU users to play with! p.s.: this is why you may have notice several disconnects today while we were deploying this new features |
|
|
|
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. Today we introduced another advanced feature for GPU miners - Fine tuning with custom speed factors and daily costs. You can now set custom hashing rate factors and even your electricity power consumption as well! This will make sure your miner mines on absolutely most profitable algorithm. You can also configure your miner, for example, to only switch between X11 and X13 (whichever is more profitable) even if globally some other algorithm is more profitable. Visit https://www.nicehash.com/multialgo/#finetuning and play around I'm sure this is one very nice tool for GPU users to play with! |
|
|
|
Right off the bat, I'm getting "thread was not cancelled in 60 seconds after restart_mining_threads"
you need to remove pool-gpu-threads from your config and use gpu-threads in the global config part Ok got it. Wait, wasn't this figured out ten pages ago? How on earth did it end up in kenshirothefist's '100% working' example config? (no worries if it was just an oversight) Well 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. So, yes, the solution is to not use "pool-gpu-threads" and use only "gpu-threads" in the global config part. |
|
|
|
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.
Yup i'm with you. Ill go back to standard mining until NiceHash Guys start posting what they are doing to address these issues 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 {
"pools" : [
{
"name" : "NiceHash_Scrypt_AS",
"url" : "stratum+tcp://stratum.nicehash.com:4333",
"user" : "BTC_addr",
"pass" : "d=1024",
"pool-algorithm" : "zuikkis",
"pool-nfactor" : "10",
"pool-thread-concurrency" : "20481",
"pool-gpu-engine" : "947-947",
"pool-gpu-memclock" : "1250-1250",
"pool-gpu-threads" : "1"
},
{
"name" : "NiceHash_Scrypt-N_AS",
"url" : "stratum+tcp://stratum.nicehash.com:4335",
"user" : "BTC_addr",
"pass" : "d=512",
"pool-algorithm" : "zuikkis",
"pool-nfactor" : "11",
"pool-thread-concurrency" : "20481",
"pool-gpu-engine" : "947-947",
"pool-gpu-memclock" : "1250-1250",
"pool-gpu-threads" : "1"
},
{
"name" : "NiceHash_X11_AS",
"url" : "stratum+tcp://stratum.nicehash.com:4336",
"user" : "BTC_addr",
"pass" : "d=0.08",
"pool-algorithm" : "darkcoin-mod",
"pool-nfactor" : "10",
"pool-thread-concurrency" : "20481",
"pool-gpu-engine" : "947-947",
"pool-gpu-memclock" : "1250-1250",
"pool-gpu-threads" : "2"
},
{
"name" : "NiceHash_X13_AS",
"url" : "stratum+tcp://stratum.nicehash.com:4337",
"user" : "BTC_addr",
"pass" : "d=0.08",
"pool-algorithm" : "marucoin-mod",
"pool-nfactor" : "10",
"pool-thread-concurrency" : "20481",
"pool-gpu-engine" : "947-947",
"pool-gpu-memclock" : "1250-1250",
"pool-gpu-threads" : "2"
},
{
"name" : "NiceHash_Keccak_AS",
"url" : "stratum+tcp://stratum.nicehash.com:4338",
"user" : "BTC_addr",
"pass" : "d=1024",
"pool-algorithm" : "maxcoin",
"pool-nfactor" : "10",
"pool-thread-concurrency" : "8960",
"pool-gpu-engine" : "947-947",
"pool-gpu-memclock" : "1250-1250",
"pool-gpu-threads" : "1"
}
],
"xintensity" : "300",
"vectors" : "1",
"kernel" : "ckolivas",
"lookup-gap" : "2",
"worksize" : "256",
"shaders" : "2560",
"thread-concurrency" : "20481",
"gpu-threads" : "1",
"gpu-engine" : "947-947",
"gpu-memclock" : "1250-1250",
"gpu-fan" : "0-95",
"gpu-powertune" : "20",
"temp-cutoff" : "95",
"temp-overheat" : "85",
"temp-target" : "75",
"auto-fan" : true,
"auto-gpu" : true,
"log" : "5",
"log-dateformat" : "1",
"failover-only" : true,
"failover-switch-delay" : "30",
"no-pool-disable" : true,
"scrypt" : true,
"queue" : "1",
"scan-time" : "7",
"expiry" : "28"
}
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. |
|
|
|
[10:48:06] Error -4: Enqueueing kernel onto command queue. (clEnqueueNDRangeKernel)
This is usually out-of-memory issue. Try lowering TC to 4096. |
|
|
|
These ports are closed now, because nscrypt is more profitable. Check main page on NiceHash - algorithm marked with green is most profitable.
If you want to mine X11 or X13, use 3336 and 3337 ports.
Thanks. I understand now how it is working. One enhancement that would be good is if you could still do the multi-algo switching to the most profitable algorithm of just the algorithms you want to mine. A lot of people are like me where scrypt mining is just to hot this time of year. You can setup only a subset of algorithms on 43xx ports if Scrypt and Scrypt-N are unacceptable due to power consumption and heat; however make sure you also setup your preferred nicehash backup pool. Example: - setup only a subset of auto-switch ports: X11:4336, X13:4337, Keccak:4338 - setup nicehash X11 backup pool: X11:3336 - this way you'll be mining the most profitable between X11, X13, Keccak - because you skipped scrypt and scrypt-N which might be the most profitable in a particular time interval and auto-switch X11:4336, X13:4337, Keccak:4338 ports will be closed, you'll be still mining X11 on nicehash X11 backup pool: X11:3336 (Note: with this configuration it might happen that X13 might still be more profitable then X11, but you'll be mining on X11 backup pool because it might happen that profitability will be like this: Scrypt > X13 > X11 ... and since Scrypt is the most profitable, X13 and X11 auto-switch would be closed). {
"pools" : [
{
"name" : "NiceHash_X11_auto-switch",
"url" : "stratum+tcp://stratum.nicehash.com:4336",
"user" : "BTC_address",
"pass" : "x",
"pool-nfactor" : "10",
"pool-algorithm" : "darkcoin-mod"
},
{
"name" : "NiceHash_X13_auto-switch",
"url" : "stratum+tcp://stratum.nicehash.com:4337",
"user" : "BTC_address",
"pass" : "x",
"pool-nfactor" : "10",
"pool-algorithm" : "marucoin-mod"
},
{
"name" : "NiceHash_Keccak_auto-switch",
"url" : "stratum+tcp://stratum.nicehash.com:4338",
"user" : "BTC_address",
"pass" : "x",
"pool-nfactor" : "10",
"pool-algorithm" : "maxcoin"
},
{
"name" : "NiceHash_X11_backup",
"url" : "stratum+tcp://stratum.nicehash.com:3336",
"user" : "BTC_address",
"pass" : "x",
"pool-nfactor" : "10",
"pool-algorithm" : "darkcoin-mod"
},
{
"name" : "some third-party X11 backup pool",
"url" : "stratum+tcp://x11-backup-pool:3333",
"user" : "user",
"pass" : "pass",
"pool-nfactor" : "10",
"pool-algorithm" : "darkcoin-mod"
}
],
"failover-only" : true,
"failover-switch-delay" : "30",
... other configuration settings ...
} |
|
|
|
I've been doing NiceHash X13 since they introduced it. It seems to be much better than X11 so far. Also they have the multi-algorithm switcher that seems interesting but haven't tried that yet. Both would be good additions to the list if you have the rigs to spare.
+1 ... suchmoon, if you need any help with multi-algo, let me know. |
|
|
|
Regarding disconnects: yesterday we had internet network connectivity issues with our stratum servers (unplanned maintenance at ISPs; BGP routing issues, etc.), that's why you may have noticed many disconnects and flips to backup pools. Thing are working smoothly now, sorry for the inconvenience and thanks for understanding. Regarding sgminer_v5 issues: as you already know, sgminer_v5 is still in development, you should regularly check: - new commits: https://github.com/sgminer-dev/sgminer/commits/v5_0- resolved issues: https://github.com/sgminer-dev/sgminer/issues?milestone=5&page=1&state=closed- open issues: https://github.com/sgminer-dev/sgminer/issues?milestone=5&page=1&state=openLot's of issues have been resolved yesterday, including errors when compiling kernels, segfaults, uptime timer, etc. If you're using sgminer_v5 and you're building from source I strongly advise you to build new version from git (git clone -b v5_0 https://github.com/sgminer-dev/sgminer.git). We'll try to provide you with windows binaries later today, but if anyone else is compiling windows binaries - your welcome to drop them here. |
|
|
|
If WafflePool took this same idea, but instead waited for authentication, checked the user's pre-defined algo weights, and rejected/accepted auth based on the best algo, we would have a pretty excellent multi-algo-profit-switching pool =].
I'm very glad that other pools are interested in multi-algo as well. I'm definetly interested in common brainstorming and development in improvments in either stratum protocol or mining software, or both - whatever that could lead into efficient algo switching at miners side. Let's share ideas in the new sgminer thread https://bitcointalk.org/index.php?topic=632503.0 (or somewhere else). BTW: regarding pre-defined algo weights - well, besides the hashrate ratio which is more or less equal for all miners, the only interesting weight is electrical power consumption. Unfortunatelly, electricity power consumption is not linear to BTC/GH/Day ratio calculation (exponential function with measured staring point should be used, and since miner doesn't know the current price ratio, he can't set power consumption weights). See also this example https://nicehash.com/multialgo/power-factor-calculation_x11.xlsx ... you can play with the numbers and you'll see that it is not trivial... but if you can come out with this logarithmic formula, please, do share it with me ... If we find this formula then we can introduce epp (electricity power price) parameter and evaluate it in the profitability formula. |
|
|
|
NiceHash brought you another innovation: NiceHash.com Best Profit Auto-Switching Multi-Algorithm GPU Mining. You can get more information here: https://www.nicehash.com/multialgo/ |
|
|
|
|
Show Posts
