Author

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

full member
Activity: 142
Merit: 101
I really would rather see the switching happen on the server end rather than the client...

That would be impossible...  the miners are on the client side.  The server just rents the hash speed out.

It might be possible with a whole new algorithm dedicated to giving hashrate to the server on the backend. It would need to be designed from the ground up just for this sole purpose.
member
Activity: 119
Merit: 10
I really would rather see the switching happen on the server end rather than the client...

That would be impossible...  the miners are on the client side.  The server just rents the hash speed out.
member
Activity: 119
Merit: 10
Seriously sexy.  My miner switched from N-Scrypt to X11 while I was away without a hitch.  This is coming along very nicely.
full member
Activity: 142
Merit: 101
Yeah this multi-algo switching thing is great, but the amount of re-working and hassle i've had to go through all over again is just plain frustrating. I'm finding that no matter how well I think my rigs are mining for a while, they always take a shit on me when im not looking, and it usually happens when a switch happens.  I really would rather see the switching happen on the server end rather than the client... i've actually given thought to scrapping the multi-algo thing and just setting up plain failover pools and switching over manually myself when i see a more profitable algorithm.
hero member
Activity: 518
Merit: 502
TopCoin Lead
Hmmm, all of my nicehash pools show 'Dead'.  Anyone else having issues?  I've been running everything without issues for a couple weeks...

Update: Must have been some some sort of network issue, came back to check 30 min later and they're aliiiive Grin
hero member
Activity: 672
Merit: 500
http://fuk.io - check it out!
member
Activity: 119
Merit: 10
Yeah I'm on 13.12 drivers and I refuse to upgrade.  You might need to start looking at different TC's to tweak the speed.  I've seen a number of 290 configs using TC 32765

I used to have 24550 on my 290's, but the 2% rejects started to bother me regardless of how great the hashrate was.  I changed it to 25600 and now my reject % is below .5%.

I think 27000 is the magic number for 290x and nscrypt.

Now, I wish I could get X11 to work right with The Stilt's BIOS...   It's great for Scrypt and N-Scrypt, but it really doesn't like X11 and X13 for some reason.
sr. member
Activity: 547
Merit: 250
Adz does that setting always crash on Windows? Or just in some special circumstances?
I have found that       "pool-gpu-threads": "2"    under Windows
Will always cause sgminer to exit after 60sec

Correct; do not employ the use of "pool-gpu-threads"
Adz
newbie
Activity: 24
Merit: 0
Adz does that setting always crash on Windows? Or just in some special circumstances?
I have found that       "pool-gpu-threads": "2"    under Windows
Will always cause sgminer to exit after 60sec
full member
Activity: 142
Merit: 101
Yep, this version doesn't work right with NScrypt and 14.1 drivers.

Here's the same config with 13.12 drivers.  Still not ideal, but better.



Yeah I'm on 13.12 drivers and I refuse to upgrade.  You might need to start looking at different TC's to tweak the speed.  I've seen a number of 290 configs using TC 32765

I used to have 24550 on my 290's, but the 2% rejects started to bother me regardless of how great the hashrate was.  I changed it to 25600 and now my reject % is below .5%.
sr. member
Activity: 547
Merit: 250
PS:  I tried my exact same conf on the 06/06 release, and I get the same results.  In case it matters, I'm on 14.1 drivers.

THAT's your problem you will only get your good results with 13.12 or older.
full member
Activity: 144
Merit: 100
You guys really mucked up the implementation of the extranonce subscription extension.  Of all the ways you could have done it, you chose the only option with the potential to create enabled mining clients that are incompatible with other pools by default.  You had full control of your stratum server implementation, and full access to nearly all client miner implementations, but little or no access to oftentimes proprietary stratum implementations at other pools, so the fact that you decided to initiate extranonce subscription messages from the mining client side, demonstrates either your incompetence or ignorance as to how to extend an already well established protocol without introducing negative consequences elsewhere, or callous disregard for the effects upon miners and the other pool operators who are affected by your protocol extension.

Given the circumstances, you should be initiating the extranonce subscription from the stratum server side, at which point an enabled mining client can respond in the appropriate fashion, and an earlier version ignore the message as you can easily verify that most mining clients do.  But as it stands now, you have created a situation where extranonce subscription enabled mining clients are sending unexpected messages to stratum servers at other pools potentially causing unknown consequences there.  Or was sabotaging your competitors part of the original plan?

I have to agree with this (except the last sentance, which is kinda stupid).. I wonder if it is already too late to change this (also, this is just a feature nicehash added, or is it some standard?). I did not go into what this is actually useful for, if it's only for these rental/multipools, then we could simply turn this option off by default (opt-in instead of opt-out).

I didn't open a github issue... but did put one out on the forum: http://coinmyne.proboards.com/thread/204/multi-algorithm-switching-sgminer

Please do open github issues. I think most of the developers (including me), are not on forums that much, compared to github where we will see the issue very fast and can respond much faster. I guarantee you, things will be fixed faster if you open an issue for it, and especially do that if multiple people are having the same problem.
For anyone who doesn't know, issues can be reported here: https://github.com/sgminer-dev/sgminer/issues (please mention if you are using the v5_0 version)
full member
Activity: 144
Merit: 100
Adz does that setting always crash on Windows? Or just in some special circumstances?
Adz
newbie
Activity: 24
Merit: 0
I can't even get this to start on windows7 x64. Starts..then closes no errors..no nothing. And trust me I have run A LOT of different cg/sgminer variations with countless kernels at this point without any problem.

Are you by any chance running it with cgwatcher? If yes start first time with batch file, than you can use cgwatcher.. don't know why Smiley

this was listed in the thread earlier

remove this code from your pool entries:

Code:
            "pool-gpu-threads": "2"
full member
Activity: 168
Merit: 100
member
Activity: 119
Merit: 10
Yep, this version doesn't work right with NScrypt and 14.1 drivers.

Here's the same config with 13.12 drivers.  Still not ideal, but better.

hero member
Activity: 700
Merit: 500
The extranonce-subscribe feature is causing so many issues with other pools... this absolutely stupid client-initiated design needs to be scrapped and replaced with a server initiated system.

I set "no-extranonce-subscribe" : true, on all pools, and so many Dead pool and auth problems stopped immediately.
member
Activity: 119
Merit: 10
Okay, I may have isolated the problem to the driver.  I recently upgraded to 14.1, and I can't get _any_ nscrypt miner to hash at the correct speed now.  So it's probably the driver.

I'll report back when I've rolled back to 13.11.
member
Activity: 119
Merit: 10
PS:  I tried my exact same conf on the 06/06 release, and I get the same results.  In case it matters, I'm on 14.1 drivers.
newbie
Activity: 31
Merit: 0
U should open an issue at github about it, don't know if there already is an issue about it.
No problem mate. Wink

I didn't open a github issue... but did put one out on the forum: http://coinmyne.proboards.com/thread/204/multi-algorithm-switching-sgminer
Jump to: