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

[beanhead]

this normal?

https://i.imgur.com/w4Lp9xX.png

because all five rigs seem to be doing only this... here's another:

https://i.imgur.com/LFV51GP.png

97 degrees is not normal!  That card won't last long if you constantly run it at that temp.

[1714929555]

1714929555

[1714929555]

1714929555

[1714929555]

1714929555

[1714929555]

1714929555

[Dabs]

Should I submit stale shares or not? What is the recommended setting?

[ixobelle]

97 degrees is not normal!  That card won't last long if you constantly run it at that temp.

ooh! nice catch.. i was too focused on the output, not checking temps. It's back down to 76 or so, not sure what it was doing there... got --temp-cutoff 95 in effect now, though. Thanks for the heads up!

[deltree]

This pool is a joke, if you guys want to know which one works wonders head to megamultipool. I had said earlier I would give this 24 hours and now its been a few more than that and I have yet to see the rejects drop.

[scryptographer]

Code:

[2014-02-10 09:30:26] Rejected 5ac5284a Diff 722/512 GPU 0 (Worker is temporarily banned

[pjv]

Should I submit stale shares or not? What is the recommended setting?

I am.

https://i.imgur.com/BKwdpzL.png

[Ritual]

I'm really not understanding the stats....

Hashrate is up and down like a gigolo's butt, but expected return is higher than I had calculated myself.... Also still trying to understand that green circle - is it a percentage of my max ever hash rate?

Rit

[tpaclassic]

I have been watching this thread for the past week, trying out the pool and something is incredibly wrong.  Not submitting stales, my total reject rates for each card averages 4-6%.  Submitting stales they all skyrocket to 50-60%.  The only way I can reduce those is to reduce the intensity on my cards down so low that I lose a total of 800 hash/775wu.  That puts the rejects to 2-4%.  I don't have to slow my cards down anywhere else I tried.  I toyed around with scantime and expiry as well, since I saw that mentioned.  No change.  I would prefer to run at my full 8Mh as opposed to running gimped.  Has anyone had any success lowering their rejects down and not having to slow down their rates?

Forgot to mention that random cards go sick or dead within 6-10 hours when I use this pool and I've been able to run them for 2-3 days straight elsewhere with no issues.

[pjv]

Code:

[2014-02-10 09:30:26] Rejected 5ac5284a Diff 722/512 GPU 0 (Worker is temporarily banned

yeah, WTF?

https://i.imgur.com/BKp7TfG.png

So maybe not a good idea to submit stales...

@Terk, i think you should fix this.

[Terk]

I'm testing major changes on a development server right now and will be deploying them to production within 2-3 hours. They should improve stability, reduce rejected ratio and prevent legitimate workers from being banned (which is happening because of very high reject ratio coming from them). In the meantime, bans are temporary and don't last for long, so your workers should be able to submit shares again within couple minutes.

I will keep you updated and let you know as soon as the changes are in production.

[Vbs]

I have been watching this thread for the past week, trying out the pool and something is incredibly wrong.  Not submitting stales, my total reject rates for each card averages 4-6%.  Submitting stales they all skyrocket to 50-60%.  The only way I can reduce those is to reduce the intensity on my cards down so low that I lose a total of 800 hash/775wu.  That puts the rejects to 2-4%.  I don't have to slow my cards down anywhere else I tried.  I toyed around with scantime and expiry as well, since I saw that mentioned.  No change.  I would prefer to run at my full 8Mh as opposed to running gimped.  Has anyone had any success lowering their rejects down and not having to slow down their rates?

Forgot to mention that random cards go sick or dead within 6-10 hours when I use this pool and I've been able to run them for 2-3 days straight elsewhere with no issues.

Scantime and Expiry should be irrelevant in a stratum pool (I have both at 9999), but Queue should be 0.

[tpaclassic]

Hmm, I figured as much for Scantime and Expiry.  I've always left queue to the default of 1, no matter where I've been.  I can try it again later after the updates.

Terk, good to know.  I'll watch for the update to try again.  I've had to disconnect my rigs from the pool for now.  I love the web page layout and the ease of information and what not.  I'd really like to continue with this pool and hope the current problems can be smoothed out!

I have been watching this thread for the past week, trying out the pool and something is incredibly wrong.  Not submitting stales, my total reject rates for each card averages 4-6%.  Submitting stales they all skyrocket to 50-60%.  The only way I can reduce those is to reduce the intensity on my cards down so low that I lose a total of 800 hash/775wu.  That puts the rejects to 2-4%.  I don't have to slow my cards down anywhere else I tried.  I toyed around with scantime and expiry as well, since I saw that mentioned.  No change.  I would prefer to run at my full 8Mh as opposed to running gimped.  Has anyone had any success lowering their rejects down and not having to slow down their rates?

Forgot to mention that random cards go sick or dead within 6-10 hours when I use this pool and I've been able to run them for 2-3 days straight elsewhere with no issues.

Scantime and Expiry should be irrelevant in a stratum pool (I have both at 9999), but Queue should be 0.

[Vbs]

Hmm, I figured as much for Scantime and Expiry.  I've always left queue to the default of 1, no matter where I've been.  I can try it again later after the updates.

Queue is actually "extra work items in queue", that's why when using 0, staged work (ST) is still at 1. It was useful back in the days before stratum, but since now work is locally generated (LW) at will by cgminer, it only serves as a hindrance on coin switches, although it shouldn't be happening.

Terk, are you sending "Clean Jobs == true" on the stratum work packet? (params[8] == true)

[Terk]

Hmm, I figured as much for Scantime and Expiry.  I've always left queue to the default of 1, no matter where I've been.  I can try it again later after the updates.

Queue is actually "extra work items in queue", that's why when using 0, staged work (ST) is still at 1. It was useful back in the days before stratum, but since now work is locally generated (LW) at will by cgminer, it only serves as a hindrance on coin switches, although it shouldn't be happening.

Terk, are you sending "Clean Jobs == true" on the stratum work packet? (params[8] == true)

Clean jobs is set to true when the pool sends new work because of new network block found. If only merkle root hash was updated, then clean jobs is false. Also, it is always set to true when sending first work for a new coin job after coin change.

Is that OK or do you think it should work differently?

[SanderHelgesen.]

51% REJECTED!!!! why?

[Vbs]

Clean jobs is set to true when the pool sends new work because of new network block found. If only merkle root hash was updated, then clean jobs is false. Also, it is always set to true when sending first work for a new coin job after coin change.

Is that OK or do you think it should work differently?

Nope, that seems correct! I'll tinker a bit more with queue sizes, since it should be flushing upon receiving clean jobs -- meaning queue size should be irrelevant too, for rejects.

[byt411]

Please get vardiff back up as soon as possible please.

[buffalojr]

I'm really not understanding the stats....

Hashrate is up and down like a gigolo's butt, but expected return is higher than I had calculated myself.... Also still trying to understand that green circle - is it a percentage of my max ever hash rate?

Rit

Green circle is a percentage of your hash rate when compared to your highest hash rate in the last 24 hours.

[Ritual]

Thanks buffalojr

[Terk]

Let me give you a status update on the pool, what issues has already been solved and what I'm going to do tonight/tomorrow to improve your experience.

1) There were some performance issues which I finished solving. They were partially affecting our profitability. Our profitability went back from 115% LTC yesterday to 176% LTC today (as of 8pm UTC, so after 20 hours) - not entire difference is because of tech issues, but they contributed to lowered profitability in recent days. As of now, the pool is running stable and profitability is good.

2) More frequent user stats and rejected percentage charts are coming to the website tonight/tomorrow.

3) Average rejected percentage has lowered to 5.6% today from 6-7% in recent days. This is no bigger than in other coin-switching pools (I've been monitoring Middlecoin and its 10-day average is 5.7%). I will make some changes that should further decrease rejected ratio as I still see one area to improve and will work on this tomorrow. The 5.6% is an average though and some users get a lot more. If you experience unusually high rejected ratio then read below to understand how intensity works and what you can do to tweak.

4) Vardiff is not going back in the next few days, but I will lower difficulty from 512 to 256. I need to upgrade one of the servers first, so difficulty will most likely change tomorrow. I will work on re-enabling vardiff next week.

More details about rejected shares percentage.

Rejected percentage actually depends on which coin we are mining. There are some coins that generate as low as 2-3% average rejected shares and there are some that generate even 15-20% rejected shares. As a rule of thumb, the faster the coin, the bigger the rejected ratio. If there is a low difficulty coin that has average block time of 30 seconds and its difficulty drops for a moment so low that it's profitable to mine it, we jump into it with our hashpower and can have blocks generated even every 10 seconds - and such speed means a lot of work will be rejected because of latency. There's not much what we can do about it. We can either ignore these coins and never mine them but it would be leaving money on the table, or we can consider it cost of doing business.

What I can and will do to make things better is to improve profitability comparison engine to correctly include past statistics of rejected shares for each coin into profitability calculations. Right now this is not always working properly. After I fix this, we will switch to a high-reject coin only if it's really worth it, so only if it's the most profitable considering that significant percent of our hashpower will be wasted. This change should also decrease overall rejected average, as we will be mining these coins less frequently than we do now. I will work on this either tonight or tomorrow (not sure how longer I will be able to work today, I hardly even sleep these days).

What to do if you have unusually high rejected ratio and why decreasing intensity might work for you.

I am no expert in rigs configuration, but this is what I learned:

If you experience unusually high rejected ratio (more than 8% 24h average), then you might want to experiment with your miners intensity settings. High intensity makes GPU work harder and calculate more hashes, but it also makes it less responsive to new block notifications. The result is that it takes more time for GPU to notice that there is a new job and the old one is no longer valid. Your GPU wastes some time to work on outdated job before it switches to a new one. And sometimes it solves work which no longer is valid, which results in a rejected share. This isn't much of a problem if new blocks come every 150 seconds as in Litecoin, but if new blocks come every 10-20 seconds, it starts becoming an issue, because percent of time wasted on GPU lag in noticing new block is significantly higher. Think of it as of some kind of a “GPU latency”. It's like network latency but on the GPU level. Unlike with network latency, you can control this GPU latency with intensity settings. The GPU will be a little less busy hashing with lower intensity and it will be noticing new blocks with smaller delay.

I know you might not like the idea of decreasing your hashpower, but there's no use of hashpower that is thrown into solving an outdated work. You should tweak intensity to get the best balance. You should be more interested in total hashrate accepted than in theoretical max hashrate. It's better to have your miner running at 1 MH/s with 5% rejects (resulting in 0.95 MH/s accepted) than at 1.1 MH/s with 20% rejects (resulting in 0.88 MH/s accepted).

Wether this will work at all depends on the GPU. What intensity level will work the best also depends on your rig. You need to experiment. If decreasing intensity will lower your hashrate by 5% but lower rejects from 20% to 5% then it's worthwhile - as I wrote, you should be interested in maximizing your accepted hashrate. The website will provide stats/charts of your rejected percentage so that you will be able to compare it to pool average and see what are effects of your miner tweaking.