[ANN][AUTO-SWITCH] Profit-switch auto-exchange pool: CleverMining.com

[Duck]

Around Nov/Dec 2013, I was mining with Middlecoin and getting around 0.001-0.004 BTC per day using a Radeon 5750. Usually getting towards the lower end of that range but getting payouts every day. Now after a 5 month break I started mining with CleverMining and the amount of BTC to be paid sucks. Checking my stats on their website (because no payouts yet), I'm getting not much more than 0.0001 BTC per day. Only 10% of what I got with Middlecoin. Why could this be?

I'll post the cgminer screenshot because to be honest, I don't really know what I am looking at. Except it says the program was started at 5am? That can't be right, I would have been asleep...

Profitability has decreased significantly since December. You can expect ~0.003 BTC per day per MH/s at this time, and you only have 0.07 MH/s, so this works out to about 0.0002 BTC per day.

You screenshot shows intensity 10, you might want to increase that.

Ah I didn't realise profitability had decreased so much in this time. I'll probably just mine in winter to keep me warmer lol.

I stick to an intensity of 10 so the system does not become unresponsive.


edit: I just shut it down and "Reject Ratio: 17.3%" seems rather high, doesn't it? This had been running all night and then all day at the point I stopped it.

In the picture you provided your real reject rate is shown on the same line as the hashrate and it's around 2%.

Ah I see it. Wonder why it said 17.3% then .

[1714878376]

1714878376

[1714878376]

1714878376

[1714878376]

1714878376

[byt411]

Around Nov/Dec 2013, I was mining with Middlecoin and getting around 0.001-0.004 BTC per day using a Radeon 5750. Usually getting towards the lower end of that range but getting payouts every day. Now after a 5 month break I started mining with CleverMining and the amount of BTC to be paid sucks. Checking my stats on their website (because no payouts yet), I'm getting not much more than 0.0001 BTC per day. Only 10% of what I got with Middlecoin. Why could this be?

I'll post the cgminer screenshot because to be honest, I don't really know what I am looking at. Except it says the program was started at 5am? That can't be right, I would have been asleep...

Profitability has decreased significantly since December. You can expect ~0.003 BTC per day per MH/s at this time, and you only have 0.07 MH/s, so this works out to about 0.0002 BTC per day.

You screenshot shows intensity 10, you might want to increase that.

Ah I didn't realise profitability had decreased so much in this time. I'll probably just mine in winter to keep me warmer lol.

I stick to an intensity of 10 so the system does not become unresponsive.


edit: I just shut it down and "Reject Ratio: 17.3%" seems rather high, doesn't it? This had been running all night and then all day at the point I stopped it.

In the picture you provided your real reject rate is shown on the same line as the hashrate and it's around 2%.

Ah I see it. Wonder why it said 17.3% then .

Because there are what we call "Fake Rejects", which are displayed as "Rejected Untracked Stratum share on pool 0", which is basically just a communication error between miner and pool.

[suchmoon]

Not sure you understand what I'm saying so here it is.  Share of difficulty of 1024 takes twice as long as difficulty 512 (approximately), right?

So let's assume that diff 1024 takes a second to solve, and 512 half-second; then in a minute miner ideally solves 60 1024 diff shares or 120 512 diff shares and total is the same (60 * 1 * 1024 = 120 * 1 * 512 = 61440).
Then let's assume that only 90% of 1024 shares are accepted, and 95% of 512 diff shares (due to block changes etc).  Then accepted work during a minute (or any other period of time) is not the same (60 * 0.9 * 1024 = 55296 < 120 * 0.95 * 512 = 56386).

So in ideal case it does average out, but that is not my point.  It does not "average out" when rejection rate is different depending on difficulty and this is what it looks like to me in case of gridseeds.  Where am I wrong?

Reject rate does not depend on pool difficulty. In the long term you will be getting the same reject rate (percentage) at diff 512 or diff 1024 or diff 1, all other things being equal.

You seem to be thinking that there is a "duration" to solve a share. There is no duration, only a probability of any given hash meeting the specified difficulty.

Regarding "speed" that cgminer shows for gridseeds, well, there should be a reference point, right?  There is the advertised speed, that is used in comparisons, and pricing of hardware, and dismiss it as "fake" is not really correct.

I just stated a fact. I even gave you an example to try if you don't believe me, since you seem to have a problem with facts. You can tell cgminer to run your Gridseed at a frequency it is not capable of running at, and cgminer will happily report a high hashrate, even though submitted shares will be low if any. You can also give cgminer an incorrect number of chips and it will report an incorrect hashrate. It does not count the actual hashes generated, it just assumes that a Gridseed at X frequency with Y chips will produce Z hashes. Here is the relevant line of code in dtbartle's cgminer, which most if not all Gridseed cgminer clones are based on:

https://github.com/dtbartle/cgminer-gc3355/blob/master/driver-gridseed.c#L705

[phzi]

Not sure you understand what I'm saying so here it is.  Share of difficulty of 1024 takes twice as long as difficulty 512 (approximately), right?

So let's assume that diff 1024 takes a second to solve, and 512 half-second; then in a minute miner ideally solves 60 1024 diff shares or 120 512 diff shares and total is the same (60 * 1 * 1024 = 120 * 1 * 512 = 61440).
Then let's assume that only 90% of 1024 shares are accepted, and 95% of 512 diff shares (due to block changes etc).  Then accepted work during a minute (or any other period of time) is not the same (60 * 0.9 * 1024 = 55296 < 120 * 0.95 * 512 = 56386).

Reject percentage will be statistically the same no matter what the difficulty - the time window in which you may mine a stale share remains exactly the same irrelevant of share diff.  So, accepted work will be statistically the same.  Look at it this way, if you on average have 10 shares per minute at 512, then you have 5 shares per minute at 1024.  If you have 6 seconds every 60 seconds where you are mining old work (which will result in a stale shares if a share is found), then on average 1/10th of all work will be stale (6/60 = 1/10).  Therefore, you would have on average (10-(10/10))*512 = 4608 diff 1 shares at diff 512, and (5-(5/10)*1024 = 4608 diff 1 shares at diff 1024. Note, they are exactly the same.

Conclusion: difficulty only affects short-term variance.  Statistically, it has NO affect on profits.

[mneehon]

Not sure you understand what I'm saying so here it is.  Share of difficulty of 1024 takes twice as long as difficulty 512 (approximately), right?

So let's assume that diff 1024 takes a second to solve, and 512 half-second; then in a minute miner ideally solves 60 1024 diff shares or 120 512 diff shares and total is the same (60 * 1 * 1024 = 120 * 1 * 512 = 61440).
Then let's assume that only 90% of 1024 shares are accepted, and 95% of 512 diff shares (due to block changes etc).  Then accepted work during a minute (or any other period of time) is not the same (60 * 0.9 * 1024 = 55296 < 120 * 0.95 * 512 = 56386).

So in ideal case it does average out, but that is not my point.  It does not "average out" when rejection rate is different depending on difficulty and this is what it looks like to me in case of gridseeds.  Where am I wrong?

Reject rate does not depend on pool difficulty. In the long term you will be getting the same reject rate (percentage) at diff 512 or diff 1024 or diff 1, all other things being equal.

I was not talking about reject rate.  In the screenshots earlier, when block changes, nothing is submitted because share is too difficult and miner didn't have a chance to finish calculation, and A: doesn't increase (neither does R:).

You seem to be thinking that there is a "duration" to solve a share. There is no duration, only a probability of any given hash meeting the specified difficulty.

Regarding "speed" that cgminer shows for gridseeds, well, there should be a reference point, right?  There is the advertised speed, that is used in comparisons, and pricing of hardware, and dismiss it as "fake" is not really correct.

I just stated a fact. I even gave you an example to try if you don't believe me, since you seem to have a problem with facts. You can tell cgminer to run your Gridseed at a frequency it is not capable of running at, and cgminer will happily report a high hashrate, even though submitted shares will be low if any. You can also give cgminer an incorrect number of chips and it will report an incorrect hashrate. It does not count the actual hashes generated, it just assumes that a Gridseed at X frequency with Y chips will produce Z hashes. Here is the relevant line of code in dtbartle's cgminer, which most if not all Gridseed cgminer clones are based on:

https://github.com/dtbartle/cgminer-gc3355/blob/master/driver-gridseed.c#L705

Here goes accusations of "having problems with facts".  I was not even talking about displayed hash rate until you mentioned it.  But are you trying to say that chips hash at the same rate regardless of clock or that 300Mhz chip is equivalent 900MHz chip and they should cost the same?  I hope not.

Or maybe you are trying to say that because hash rate displayed in miner is meaningless nobody should ever care about it?
And if that's the case, I'll gladly rent your 10Mh/s rig and pay for 1kh/s.

Reject percentage will be statistically the same no matter what the difficulty - the time window in which you may mine a stale share remains exactly the same irrelevant of share diff.  So, accepted work will be statistically the same.  Look at it this way, if you on average have 10 shares per minute at 512, then you have 5 shares per minute at 1024.  If you have 6 seconds every 60 seconds where you are mining old work (which will result in a stale shares if a share is found), then on average 1/10th of all work will be stale (6/60 = 1/10).  Therefore, you would have on average (10-(10/10))*512 = 4608 diff 1 shares at diff 512, and (5-(5/10)*1024 = 4608 diff 1 shares at diff 1024. Note, they are exactly the same.

Conclusion: difficulty only affects short-term variance.  Statistically, it has NO affect on profits.

Now this is interesting.  I think that in second calculation you have to truncate, you cannot submit half of share, is that correct?  So resulting diff 1 shares will be Trunc( 5 - 0.5 ) * 1024 = 4096, is it not?  I mean it will probably work out in a longer (much longer) run but not in a short one.

I'm going to try an experiment...

[suchmoon]

I was not talking about reject rate.  In the screenshots earlier, when block changes, nothing is submitted because share is too difficult and miner didn't have a chance to finish calculation, and A: doesn't increase (neither does R:).

I'm going to give up on this. Phzi already gave you a "fingers and toes" example, can get any more basic than that.

I was not even talking about displayed hash rate until you mentioned it.

Really  I was directly responding to this:

Also looking at graphs on betarigs (damn those graphs) I can clearly see that GPU that I lease shows accepted average rate within 0-1% of what cgminer shows, whereas 8-10 pods gridseed rigs consistently show accepted average rate 10-15% lower than what cgminer shows.

What do you mean then by "cgminer shows"?

But are you trying to say that chips hash at the same rate regardless of clock or that 300Mhz chip is equivalent 900MHz chip and they should cost the same?  I hope not.

Or maybe you are trying to say that because hash rate displayed in miner is meaningless nobody should ever care about it?
And if that's the case, I'll gladly rent your 10Mh/s rig and pay for 1kh/s.

I said that you should not trust cgminer's gridseed hashrate, but look at "A:" instead. That was again in response to your statement that "graphs" show 10-15% lower rate than cgminer, and I explained why that could be. Betarigs graphs are based on shares, cgminer numbers are based on inaccurate assumptions. I never said that 300Mhz and 900MHz are the same, or that 10Mh/s somehow equals 1Kh/s. If you had tried the example configurations I gave you or at least looked at that one line of code it would be quite obvious what's going on. If you don't like my explanation that's fine, I'll survive that 

[phzi]

Now this is interesting.  I think that in second calculation you have to truncate, you cannot submit half of share, is that correct?  So resulting diff 1 shares will be Trunc( 5 - 0.5 ) * 1024 = 4096, is it not?  I mean it will probably work out in a longer (much longer) run but not in a short one.

I'm going to try an experiment...

Of course you cannot submit half shares, that would be an invalid share (reason: below target).  The key here is to realize that no matter what your share difficulty is, each diff 1 share has the same probability of being stale.  Whether you are submitting the equivalent of 512 or 1024 "diff 1 shares" (or any other number of diff 1 shares) at a time, is entirely irrelevant.  Truncating or rounding would never come into calculating these statistics.

[Hatch]

We could really use some more hashpower to reduce variance and provide more stable results with decreased luck factor. But even with our current hashrate you don't need to worry about our profitability in the longer term. We will have bigger daily ups and downs during times of LTC mining, but the long term average will still be good. And when there will be some new coins rising then you can be sure that CM is the pool to be on. ~ Terk

Heya Terk!

Please understand that I write this after reading all of the associated posts previous, and with what I believe to be a clear understanding of what you have said relating to this issue thus far...


New board member, big fan of what you have accomplished to date with CleverMining. I am fairly new to this whole mining gig, but am a quick study and have two 5MHash rigs running very nicely now with SGMiner 4.1.271.

To make a long story short, I think if you want more hashpower, we HAVE to figure out if there is anything possible that can be done to iron out what arguably seems to be an abnormally high reject rate.

Once I got my machines running stable, I used "Mining Performance Charts" and "PoolPicker" to figure out which pools to try for best BTC/Mhs. I have tried Wafflepool, ScryptGuild, HashCows, CoinFu... Most all of them for at least 24 hours, a few of them a LOT longer, including CleverMining. That said, I am sure a lot of other folks around here have as well.

Hands down, I like the operational feedback and stat presentation of CleverMining above all the rest. Most times the relative profitability too. "And here it comes"...  

But!

So I have been mining with you pretty steady since 4/18 until the bottom dropped out a few days ago (again?) and figured I might try the rig leasing option a bit to see how that goes, so I swapped to NiceHash for a couple of days and did above average there. Now with all of this experimentation, there is no question from my experience that for whatever reason, the only way I can get a slightly above comparable reject rate as I get everywhere else is to start backing down on my xintensity. In my case, I have to back it off about 10% to average around  a 1.5-3% reject rate which is still higher than the .5-2% I average I get almost everywhere else with my optimal settings. No sweat, I can deal... I like your service enough to take a small hit in performance to get "cleaner" work stats and appreciate the rest of what you have to offer... As long as I can get a decent hash/power ratio and come in equal or below the "Montreal/Canada Average Rejected" rate, Im happy...

But I come back to CleverMining this afternoon, and with those same conservative settings I am now averaging 6.6%? As I said before, I truly prefer your service, but it is getting to the point where to get rejects under control, we have to de-tune the rigs to a degree that they are no longer operating anywhere near full capacity for the power we use, and especially so in relation to the rest of the failover options in our conf files.

Please understand that my intent with this post is in no way meant to belittle or criticize your awesome work. You have done an outstanding job thus far and I hope you understand how much we all appreciate your efforts. My intent here is simply an effort to bring to your attention what in my mind is arguably the only hindrance to the growth that I believe CleverMining is capable of. As much as any of us might prefer yours or any other service over the others for any variety of reasons, the bottom line is ROI. From this perspective, throwing away 660Kh in rejects or de-tuning the rigs to basically the same amount of loss in effective hash rate to get rid of the rejects just doesn't seem reasonable when viewed in context with the accept/reject performance of your growing number of competitors. It's like tossing two of your Gridseeds or one of your GPU's (without the corresponding reduction in power) when you use this service because they simply don't count here. As much as you already have over and above the "other guys" with your achievements thus far, this issue is not conducive to our ROI, and therefore your potential for growth. Because of my experience as a software producer I am well aware that you may or may not be able to get a handle on this. But hopefully, with your full attention and proven capabilities, something can be done to address it sooner rather than later.


Thanks for all you do!

Hatch

[phzi]

But I come back to CleverMining this afternoon, and with those same conservative settings I am now averaging 6.6%? As I said before, I truly prefer your service, but it is getting to the point where to get rejects under control, we have to de-tune the rigs to a degree that they are no longer operating anywhere near full capacity for the power we use, and especially so in relation to the rest of the failover options in our conf files.

Multi-pools switch between multiple coins, and some of those coins have a very low-diff and/or a fast block time.  If CM starts mining a low-diff coin, rejects go up because the block find rate is high (so, there is a large percentage of time when a found share will be stale); if it's a fast block coin too (say, <1min block times) this compounds the issue and rejects go even higher.  Every other multi-pool encounters the same thing - WafflePool has periods of 10% reject rate, but settles around 3% overall.

As for 'de-tuning' your rigs - this is expected and necessary.  The optimal tuning for maximum accepted shares varies significantly between coins.  Since a multi-pool is mining many coins, you have to at least partially tune of the lowest common denominator (specifically lower xI values for faster coins).

It's important to note that any decent multi-pool (CM and WP for example), almost certainly consider reject rates in their coin selection algorithms.  So, if you're mining with 10% rejects for a while, that coins is going to be probably 15% more profitable then the next best option (so, 5% more profitable when accounting for rejects).

[mneehon]

I said that you should not trust cgminer's gridseed hashrate, but look at "A:" instead. That was again in response to your statement that "graphs" show 10-15% lower rate than cgminer, and I explained why that could be. Betarigs graphs are based on shares, cgminer numbers are based on inaccurate assumptions. I never said that 300Mhz and 900MHz are the same, or that 10Mh/s somehow equals 1Kh/s. If you had tried the example configurations I gave you or at least looked at that one line of code it would be quite obvious what's going on. If you don't like my explanation that's fine, I'll survive that 

Well, you don't really explain anything, I'm fine with that.  I'm not sure what you mean by "at least looked at that one line of code".  Yes it depends on chip clock, yes it depends on number of chips, yes, it depends on time per something that's coming from chip info structure (I assume live value) and some constant defined elsewhere.  So what?  Doesn't GPU calculation do essentially the same (GPU clock * number of calc units * some constant * variable time per calc) (I'm sorry I'm too lazy to dig up the actual line of code)?

About betarigs graphs, for GPU what betarigs shows is almost exactly what cgminer shows, for GS what betarigs shows is 5-15% lower than what cgminer shows (and it's worse for larger arrays with higher number of GS pods).  Regardless of your explanation, claimed rig speed has to be adjusted for inefficiency, and for larger gridseed arrays it is higher than for smaller.  When you lease out your rigs, what is the base for the claimed speed?  Do you get it from cgminer/bfgminer or painstakingly calculate based on A: value?

And I ran the suggested experiment, about hour and a half right now (highly unscientific).  Two gridseed rigs, four pods each, same clock etc one pointing to specific coin with difficulty 256-512 and little block restarts, another to clevermining with steady difficulty 512 and lots of restarts.

Current results:
rig 1 (other pool, lower diff, less restarts): A:112384 R:0 WU:4.1
rig 2 (CM pool, higher diff, more restarts): A:105984 R:2048 WU:2.4

about 4% difference including rejects, and so far second rig is not closing in on the first (and first is having plenty of restarts too, bad example actually.)

Maybe you can do the same experiment and report your results?

[Kalizar]

Scrypt multipool is kinda dead guys.

Vertcoin just came out with merged mining. I am mining Vertcoin, Monoclecoin, and Parallaxcoin at the same time! My hashes are sent to each blockchain so there is no loss of hash rate. So I am mining 1.25 MH/s Vertcoin, 1.25 MH/s Monoclecoin, and 1.25 MH/s Parallaxcoin. This just came out from the Vertcoin devs on Friday and tons of people are jumping in.

I have a feeling I will be merged mining with 50+ coins soon. ^_^

[phzi]

Current results:
rig 1 (other pool, lower diff, less restarts): A:112384 R:0 WU:4.1
rig 2 (CM pool, higher diff, more restarts): A:105984 R:2048 WU:2.4

about 4% difference including rejects, and so far second rig is not closing in on the first (and first is having plenty of restarts too, bad example actually.)

Maybe you can do the same experiment and report your results?

Total work should end up statistically the same.  Your sample period is much too short (as you said) to mean anything.

Also, work restarts shouldn't result in any lost work or lost working time.

Scrypt multipool is kinda dead guys.

Vertcoin just came out with merged mining. I am mining Vertcoin, Monoclecoin, and Parallaxcoin at the same time! My hashes are sent to each blockchain so there is no loss of hash rate. So I am mining 1.25 MH/s Vertcoin, 1.25 MH/s Monoclecoin, and 1.25 MH/s Parallaxcoin. This just came out from the Vertcoin devs on Friday and tons of people are jumping in.

I have a feeling I will be merged mining with 50+ coins soon. ^_^

And what do you plan to do with your Monocle and Parallax lol?  It's great that you can merge-mine stuff, but you can't sell it for BTC (at least not yet), so it's not really relevant to multi-pools.  There are merge-mined scrypt coins too, but nobody mines them because it's pointless.  (This said, I am stashing some Monocle away to see what happens).

[goodluck0319]

where is site?

[phzi]

where is site?

http://www.clevermining.com/
?

[Kalizar]

Current results:
rig 1 (other pool, lower diff, less restarts): A:112384 R:0 WU:4.1
rig 2 (CM pool, higher diff, more restarts): A:105984 R:2048 WU:2.4

about 4% difference including rejects, and so far second rig is not closing in on the first (and first is having plenty of restarts too, bad example actually.)

Maybe you can do the same experiment and report your results?

Total work should end up statistically the same.  Your sample period is much too short (as you said) to mean anything.

Also, work restarts shouldn't result in any lost work or lost working time.

Scrypt multipool is kinda dead guys.

Vertcoin just came out with merged mining. I am mining Vertcoin, Monoclecoin, and Parallaxcoin at the same time! My hashes are sent to each blockchain so there is no loss of hash rate. So I am mining 1.25 MH/s Vertcoin, 1.25 MH/s Monoclecoin, and 1.25 MH/s Parallaxcoin. This just came out from the Vertcoin devs on Friday and tons of people are jumping in.

I have a feeling I will be merged mining with 50+ coins soon. ^_^

And what do you plan to do with your Monocle and Parallax lol?  It's great that you can merge-mine stuff, but you can't sell it for BTC (at least not yet), so it's not really relevant to multi-pools.  There are merge-mined scrypt coins too, but nobody mines them because it's pointless.  (This said, I am stashing some Monocle away to see what happens).

PLX is already on an exchange where I am dumping it lol. Like I said, this is only a few days old so wait for coin devs to make more coins. This will be the next wave of mining for GPU miners. ^_^

[phzi]

PLX is already on an exchange where I am dumping it lol. Like I said, this is only a few days old so wait for coin devs to make more coins. This will be the next wave of mining for GPU miners. ^_^

With the massive buy orders totaling around .001 BTC?  Yay... you can sell 50 cents worth of PLX...

I highly doubt these merge-mined coins will be worth mining anytime soon.  I mean really, most altcoins have effectively 0 utility; merge-mined coins have even less unless they implement an interesting non-currency use like namecoin did.

[Kalizar]

PLX is already on an exchange where I am dumping it lol. Like I said, this is only a few days old so wait for coin devs to make more coins. This will be the next wave of mining for GPU miners. ^_^

With the massive buy orders totaling around .001 BTC?  Yay... you can sell 50 cents worth of PLX...

I highly doubt these merge-mined coins will be worth mining anytime soon.  I mean really, most altcoins have effectively 0 utility; merge-mined coins have even less unless they implement an interesting non-currency use like namecoin did.

That is pretty much how 95% of alt coins are already. However, miners no longer have to take the risk of a coin failing when mining. They can get VTC still.

Yes, 50 cents is little money... but it adds up. When miners are merge mining 50 coins, that would be theoretically 25 USD and so on. PLX is a pre-mined coin that really doesn't offer much with innovation and community. Soon devs, with innovative ideas, will be able to release a coin that rewards miners in VTC. At least then they can still cover their electricity(depending where you live).

[suchmoon]

Well, you don't really explain anything, I'm fine with that.  I'm not sure what you mean by "at least looked at that one line of code".  Yes it depends on chip clock, yes it depends on number of chips, yes, it depends on time per something that's coming from chip info structure (I assume live value) and some constant defined elsewhere.  So what?  Doesn't GPU calculation do essentially the same (GPU clock * number of calc units * some constant * variable time per calc) (I'm sorry I'm too lazy to dig up the actual line of code)?

I don't think I mentioned anything about GPUs, but I'm sure that the inaccuracy in Gridseed hashrate calculation can account for the difference you were seeing. You think that doesn't explain it - ok, let's leave it at that.

Maybe you can do the same experiment and report your results?

You didn't think I would make claims without actually having tested and understood the concept, did you? :-)

There you go - pool, diff, A:, R:

WafflePool 512 941568 17408
CleverMining 512 968704 22016
Middlecoin 1024 952144 16384
ScryptGuild 128 953600 4480
CoinShift VARDIFF 960448 10240
TradeMyBit VARDIFF 933632 7872
Hashco.ws VARDIFF 943440 20944
DogeP2P VARDIFF 958411 10220

Uptime approximately 12 hours 20 minutes. Four 5-chip Gridseeds for each pool. Scryptguild claims to be VARDIFF, but it never switched away from 128. TMB is low because it actually disconnects on coin switch, most other pools have figured out switching without disconnecting.

[Xenocyde]

But I come back to CleverMining this afternoon, and with those same conservative settings I am now averaging 6.6%? As I said before, I truly prefer your service, but it is getting to the point where to get rejects under control, we have to de-tune the rigs to a degree that they are no longer operating anywhere near full capacity for the power we use, and especially so in relation to the rest of the failover options in our conf files.

Yet another person that doesn't really know how to read the reject rate. Seriously, guys, soemone needs to put this in the OP and on the site FAQ. Otherwise people freak out and write long posts for nothing.

Hatch, are you reading the rejects rate from the hashrate line or the uppermost line in SGminer? If you'd check out the hashrate line, you'd see that the real reject rate is under 1% after 2-3 days of uptime.

[rsx19]

if i have multiple rigs and want to see individual stats do i use "btc_rig1"

or somethihng along the lines of that?? or if i do that will it cant it as a differnt address