[ANN] NiceHash.com - sell & buy hash rate cloud mining service / multipool - page 331.

phzi

hero member

Activity: 700

Merit: 500

My 'idle miner' patch that has been effective on my rigs is a single line change:

in util.c, auth_stratum function

Either immediately before or immediately after the 'JSON stratum auth failed' applog, add one line:

Code:

pool->idle = true;

This correctly marks the pool as 'Dead,' after a failed stratum auth, and the next alive pool will be chosen. Because the pool is marked idle, a reconnect attempt will be made periodically. If auth is succesful, the pool is marked 'Alive,' and mining resumes.

Without this 1 liner, the pool is still seen as alive after a failed auth. So, sgminer sits and waits for work even tho the connection was not successful. (Truthfully, the connection and auth are seperate ideas in the stratum protocol, so you can connect but fail auth, in which case you did 'connect' successfully).

Note, of course, I offer this 1 line of code with no warranty whatsoever. You have been warned! ;-]

comeonalready

full member

Activity: 168

Merit: 100

Quote from: elbandi on April 24, 2014, 08:13:43 PM

All cgminer and clones are affected in this idlebug. Thus, pls send the fix to the author of cgminer. If the patch is really good, he will accept it and merge to cgminer. And you'll get what you deserve and everyone will be happy. Cheesy

You only chose to work on this project because a fee was offered. So are you really suggesting that I should now offer my solution for free? I'll pass. And as I have already stated, you will probably eventually be able to find and fix the problem too, but what value do you place on your time?

elbandi

hero member

Activity: 525

Merit: 531

Quote from: comeonalready on April 24, 2014, 07:54:33 PM

We (all three of us) are apparently a stubborn lot.

All cgminer and clones are affected in this idlebug. Thus, pls send the fix to the author of cgminer. If the patch is really good, he will accept it and merge to cgminer. And you'll get what you deserve and everyone will be happy. Cheesy

comeonalready

full member

Activity: 168

Merit: 100

Quote from: nicehashdev on April 24, 2014, 07:31:15 PM

I gave your contact to elbandi - from here on, it is his choice whether he wants to solve it on his own or use your solution and give you cut out of his reward.

We (all three of us) are apparently a stubborn lot.

Nicehash currently has more orders than it can fill. At 4% rake and 6.2 BTC/GH/Day, if miners with only 1GH/s worth of scrypt hashpower alone are staying away because of this idle bug, then that equates to approximately 0.25 BTC per day lost in incremental revenue. As two days have gone by, that makes approximately 0.5 BTC potentially lost. Tomorrow will make 0.75 BTC if the fix is not found. There have been repeated posts here from miners who are experiencing this problem stating that they can not use nicehash again until it is addressed. And when you do solve the problem, you might just land a mega-miner. Who is in charge of making the financial decisions there?

nicehashdev

sr. member

Activity: 280

Merit: 250

I gave your contact to elbandi - from here on, it is his choice whether he wants to solve it on his own or use your solution and give you cut out of his reward.

comeonalready

full member

Activity: 168

Merit: 100

Quote from: nicehashdev on April 24, 2014, 05:10:19 PM

Quote from: qbitx on April 24, 2014, 05:08:05 PM

Quote from: nicehashdev on April 24, 2014, 02:11:54 PM

Yes, miner subscribes to extranonce changes and receives extranonce updates just like job updates. If miner does not subscribe to extranonce, server will never send mining.set_extranonce. With set_extranonce, next work has to be built with new extranonce. The sequence of methods send from NiceHash is following when switching order:

mining.set_extranonce
mining.set_difficulty
mining.notify

That means switching order is as fast as changing work/job. No more reconnects. If there are orders paying less than what you want, you will be of course disconnected.

Does this fork of sgminer address the idle bug, or is that still a work in progress?

Work in progress.

Several days ago I was investigating this idle bug to satisfy my own curiosity and offered to provide the fix to you for free if I found it. I found and fixed it two days ago, but you had already hired someone else to do the work instead, so obviously I can no longer give it away for nothing. Today, that person contacted me for some information about the bug, so I assume he has not yet found it. I have no doubt that he or someone else eventually will, but how long it will take is anyone's guess, as it is nested pretty deeply in the muck.

I offered the fix to you for a token amount -- a quarter of what you were paying him -- and also to send the fix in advance of payment for verification, but you declined. So how long it remains a work in progress is really up to you...

nicehashdev

sr. member

Activity: 280

Merit: 250

Quote from: qbitx on April 24, 2014, 05:08:05 PM

Quote from: nicehashdev on April 24, 2014, 02:11:54 PM

Yes, miner subscribes to extranonce changes and receives extranonce updates just like job updates. If miner does not subscribe to extranonce, server will never send mining.set_extranonce. With set_extranonce, next work has to be built with new extranonce. The sequence of methods send from NiceHash is following when switching order:

mining.set_extranonce
mining.set_difficulty
mining.notify

That means switching order is as fast as changing work/job. No more reconnects. If there are orders paying less than what you want, you will be of course disconnected.

Does this fork of sgminer address the idle bug, or is that still a work in progress?

Work in progress.

qbitx

newbie

Activity: 34

Merit: 0

Quote from: nicehashdev on April 24, 2014, 02:11:54 PM

Yes, miner subscribes to extranonce changes and receives extranonce updates just like job updates. If miner does not subscribe to extranonce, server will never send mining.set_extranonce. With set_extranonce, next work has to be built with new extranonce. The sequence of methods send from NiceHash is following when switching order:

mining.set_extranonce
mining.set_difficulty
mining.notify

That means switching order is as fast as changing work/job. No more reconnects. If there are orders paying less than what you want, you will be of course disconnected.

Does this fork of sgminer address the idle bug, or is that still a work in progress?

nicehashdev

sr. member

Activity: 280

Merit: 250

Yes, miner subscribes to extranonce changes and receives extranonce updates just like job updates. If miner does not subscribe to extranonce, server will never send mining.set_extranonce. With set_extranonce, next work has to be built with new extranonce. The sequence of methods send from NiceHash is following when switching order:

mining.set_extranonce
mining.set_difficulty
mining.notify

That means switching order is as fast as changing work/job. No more reconnects. If there are orders paying less than what you want, you will be of course disconnected.

phzi

hero member

Activity: 700

Merit: 500

Quote from: nicehashdev on April 24, 2014, 12:31:59 PM

Who does compile his own sgminer, you can start testing extranonce subscription feature, which enables no more reconnects during order switch.

https://github.com/bitbandi/sgminer/commits/nicehash-extranonce

Awesome.

So, the miner sends a subscribe to extranonce updates before auth, telling the server it supports extranonce updates. Then, the server sends a stratum notification when the extranonce needs to change?

Looks clean. Will throw this on my rigs and see how it goes.

nicehashdev

sr. member

Activity: 280

Merit: 250

Who does compile his own sgminer, you can start testing extranonce subscription feature, which enables no more reconnects during order switch.

https://github.com/bitbandi/sgminer/commits/nicehash-extranonce

phzi

hero member

Activity: 700

Merit: 500

Quote from: dhsc19 on April 24, 2014, 11:24:40 AM

I can only get "bursts" of 1/2 the hash rate on my R9 280X with all the various suggested settings (overclocking, 8193 thread, xintensity, etc.) I'm just not get a steady rate unfortunately and it averages less than 1/2 for me. Will just have to keep watching to see when it will become more profitable for me.

Also keep in mind that most people see fairly significant power savings when hashing scrypt(n=11) vs scrypt(n=10). My 290s can be tuned up to 470KH/s with low reject rates, and use less power then when they are hashing scrypt at 850KH/s.

Quote from: dhsc19 on April 24, 2014, 11:24:40 AM

Anyone trying the mixed algo configs on the development versions of sgminer? You can set up load-balanced or quota pools to mine scrypt and nfactor at the same time on a single GPU. Or set up failover mode, primary pool mines scrypt and failover mines nfactor. Would be interesting to see how the "p=" setting can play into getting the GPU to mine nscrypt only when its profitability it higher than scrypt. It might be interesting to try once the idle bug is fixed and implemented in the capable versions of sgminer.

I made a post somewhere above about this. I showed how you can use p= to automatically switch between nscrypt and scrypt depending on what is more profitable (within a margin of error). The idle bug does throw a bit of a wrench in this tho.

(Personally, I'm not mining here until the idle and p= problems are resolved. But I have been buying hashing power on occasion.)

dhsc19

member

Activity: 96

Merit: 10

Quote from: phzi on April 24, 2014, 03:05:32 AM

Quote from: dhsc19 on April 24, 2014, 02:46:49 AM

I'm not sure what advantage I would have as a provider for scrypt-adaptive-n. The bids are just below twice as much as scrypt and my hash rate is cut to 1/3 to 1/2. The bids need to be at least two or three times that of scrypt just for me to meet the amount I could earn providing for scrypt. Is there everyone providing for scrypt-adaptive-n meeting or beating the earnings compared to providing for scrypt?

With skilled tuning, you can get 55%+ out of an nscrypt rig. Recently, there have been a few times where nscrypt was more profitable then scrypt for my rigs on nicehash, and the price went above 11BTC/GH for a bit.

I think as more scrypt ASIC miners roll out (presuming there is really any reason to have alternative blockchains beyond BTC and LTC), nscrypt will become increasingly more profitable for GPU miners.

I can only get "bursts" of 1/2 the hash rate on my R9 280X with all the various suggested settings (overclocking, 8193 thread, xintensity, etc.) I'm just not get a steady rate unfortunately and it averages less than 1/2 for me. Will just have to keep watching to see when it will become more profitable for me.

Anyone trying the mixed algo configs on the development versions of sgminer? You can set up load-balanced or quota pools to mine scrypt and nfactor at the same time on a single GPU. Or set up failover mode, primary pool mines scrypt and failover mines nfactor. Would be interesting to see how the "p=" setting can play into getting the GPU to mine nscrypt only when its profitability it higher than scrypt. It might be interesting to try once the idle bug is fixed and implemented in the capable versions of sgminer.

nicehashdev

sr. member

Activity: 280

Merit: 250

We are working hard to bring you fixed mining software (cgminer & sgminer). Fixes will include:
- idlebug fix
- new stratum method to change extranonce1 - no more reconnects needed when switching orders
- cgminer 3.7.2 with above + fixed extranonce bug

phzi

hero member

Activity: 700

Merit: 500

Quote from: dhsc19 on April 24, 2014, 02:46:49 AM

I'm not sure what advantage I would have as a provider for scrypt-adaptive-n. The bids are just below twice as much as scrypt and my hash rate is cut to 1/3 to 1/2. The bids need to be at least two or three times that of scrypt just for me to meet the amount I could earn providing for scrypt. Is there everyone providing for scrypt-adaptive-n meeting or beating the earnings compared to providing for scrypt?

With skilled tuning, you can get 55%+ out of an nscrypt rig. Recently, there have been a few times where nscrypt was more profitable then scrypt for my rigs on nicehash, and the price went above 11BTC/GH for a bit.

I think as more scrypt ASIC miners roll out (presuming there is really any reason to have alternative blockchains beyond BTC and LTC), nscrypt will become increasingly more profitable for GPU miners.

dhsc19

member

Activity: 96

Merit: 10

I'm not sure what advantage I would have as a provider for scrypt-adaptive-n. The bids are just below twice as much as scrypt and my hash rate is cut to 1/3 to 1/2. The bids need to be at least two or three times that of scrypt just for me to meet the amount I could earn providing for scrypt. Is there everyone providing for scrypt-adaptive-n meeting or beating the earnings compared to providing for scrypt?

dopedick47

newbie

Activity: 17

Merit: 0

When is x11 coming?

Goolicious

newbie

Activity: 4

Merit: 0

Hello,

I got a little problem with my miner (SHA-256).

I use the "p=0.08" to let it start, if the price goes to 0.08/THs/day and above.
But it is mining right away for a lower amount.

Did I configure something wrong?

Thanks in advance.

nicehashdev

sr. member

Activity: 280

Merit: 250

PPS, Proportional.

But any system will be OK, if you limit the speed and mine for longer time.

Vitalogy

sr. member

Activity: 294

Merit: 250

I'm wondering, as a buyer what is the best pool reward system to look for? Knowing that I will mine with a high hashrate on a relatively short time.

Am I correct to think that Proportional & PPS are the best?

What about PPLNS? A popular reward system is to pay the shares submited in the last X minutes.
So what happen if the pool don't find a block while I'm mining during that X minutes long round? I get no reward. Right?

Topic: [ANN] NiceHash.com - sell & buy hash rate cloud mining service / multipool - page 331. (Read 794443 times)