2 ideas for long down the road;
1) Mobile app for monitoring hash rates. I used this on MC to remote in when there was an issue and resolve it when on the go and away from a computer,
2) Make an option for miners to keep the alt coins instead of auto exchanging for BTC. I love the idea behind Hashcows. I want to expand my coin portfolio in case some coin jumps up a ton some day. No biggie if not. I'm sure this is a huge, hard endeavor.
Topic: [ANN][AUTO-SWITCH] Profit-switch auto-exchange pool: CleverMining.com - page 286. (Read 554387 times)
February 10, 2014, 08:05:34 PM
February 10, 2014, 08:03:01 PM
Exactly, look at this: http://www.clevermining.com/users/1PLmgYkcKurwzyTQo4fBgg7Pm7mt93qrk3
Ready for payout 0.006, unexchanged 0.033 ?
Definitely not right.
Ready for payout 0.006, unexchanged 0.033 ?
Definitely not right.
I am in the same boat. I suspect that Terk was busy working on fixes and just hasn't exchanged coins yet. No big deal so far especially with prices down atm anyways. My un-exchanged is sitting at 0.04301213 BTC atm lol
Nice work Terk! Love the pool, website and fast response time! Keep it up!
February 10, 2014, 07:58:45 PM
@Terk: question on the hashrate chart. i have been pushing a consistent 1.2 - 1.4 mH since sometime yesterday, but after hour 12 on the chart below, the stat graph fell off a cliff for some reason. i have been monitoring my rig all day and my hashrates have stayed over 1.2. since this morning i have also (finally) had consistently low rejects (running under 2% all day so far). what is up with this graph?
https://i.imgur.com/IPdKojI.png
also seeing pretty high ratio of unexchanged coins in my account.
https://i.imgur.com/IPdKojI.png
also seeing pretty high ratio of unexchanged coins in my account.
February 10, 2014, 07:56:34 PM
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.
Weirdly I tried setting my queue to 0 in my 50-50 config that load balances between Clever and Middle, and my rejects went up a lot to over 10%. I set it back to 3 where I had it previously and now rejects are back in the 2% range.
February 10, 2014, 07:55:41 PM
Exactly, look at this: http://www.clevermining.com/users/1PLmgYkcKurwzyTQo4fBgg7Pm7mt93qrk3
Ready for payout 0.006, unexchanged 0.033 ?
Definitely not right.
Ready for payout 0.006, unexchanged 0.033 ?
Definitely not right.
February 10, 2014, 07:25:08 PM
Thanks for the update. Nice to see all these changes happening quickly. Just out of curiosity, anyone else have quite a bit of unexchanged? I have .0098 ready to be paid, and .012 still waiting unexchanged. Haven't had a payout for awhile but my 24hr profit is .010 so I'm pretty happy.
February 10, 2014, 07:18:25 PM
getting lots of rejects, ~33%, but a new block is happening very quckly.......must be a very low dif coin. Hopefully the difficulty lower will help when that happens for these low dif coins.
February 10, 2014, 06:43:31 PM
Sounds like some of the updates I was waiting for. I've moved things over to see what happens and have already noticed a huge reduction in the rejections I was seeing earlier! In fact, I'm using the settings I was using previously on other sites, including what was my primary auto switching pool. Thanks for keeping on top of it all!
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.
February 10, 2014, 06:16:36 PM
Why quote the whole text dude?
Profits are everywhere better, please add an EU server.
Like the site/pool, good work done so far
Profits are everywhere better, please add an EU server.
Like the site/pool, good work done so far
February 10, 2014, 05:09:32 PM
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.
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.
You're doing a fine job, Terk. Profitability jump today shows that. Well done!
February 10, 2014, 05:06:07 PM
Thanks Terk, for great support and fixing problems ASAP.
I will have a rig up in the next few weeks and I will point it at your pool.
I will have a rig up in the next few weeks and I will point it at your pool.
February 10, 2014, 05:00:52 PM
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.
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.
February 10, 2014, 02:47:53 PM
Thanks buffalojr 
February 10, 2014, 02:18:16 PM
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
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.
February 10, 2014, 01:19:50 PM
Please get vardiff back up as soon as possible please.
February 10, 2014, 01:05:55 PM
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?
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.
February 10, 2014, 12:57:00 PM
51% REJECTED!!!! why?
February 10, 2014, 12:40:02 PM
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?
February 10, 2014, 12:12:36 PM
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)
February 10, 2014, 11:19:58 AM
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!
Scantime and Expiry should be irrelevant in a stratum pool (I have both at 9999), but Queue should be 0.
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.
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.
Jump to: