Author

Topic: [ANN][AUTO-SWITCH] Profit-switch auto-exchange pool: CleverMining.com - page 223. (Read 554387 times)

hero member
Activity: 616
Merit: 522
haven't gotten paid in over 20 hours, is there any issues with payouts?

14wfY1fwNXqkKHafemxW3poWpLcMgWFvo6

You also haven't been mining for 26 hours, so your balance didn't increase since then. You will be paid tomorrow when 0.001 BTC payouts will be send. Also tomorrow I should fetch into database some manual payouts so your unexchanged balance should convert to ready to pay and be paid as well.
sr. member
Activity: 350
Merit: 250
@ engine 1070/memclock 1500 3x r9 280x i am getting 30% reject but WU: 98%
newbie
Activity: 59
Merit: 0
haven't gotten paid in over 20 hours, is there any issues with payouts?

14wfY1fwNXqkKHafemxW3poWpLcMgWFvo6
hero member
Activity: 616
Merit: 522
Could you add an option to be paid only once per day?

I had really lot (and I mean a lot) people complaining about micropayouts every couple of hours. Basically most of people with enough hashpower to be paid every couple of hours complained about it.

I think the rest of us enjoy being paid more often.  I am sure Terk likes the security of it as well.  He does not have to hold large balances, just in case of attack.

I thought it as well, the ongoing payouts will allow me to keep less of your Bitcoins in my wallet, but it isn't the case. Balances of people having less than 0.01 BTC are stacking up.

What I'm going to do is to make one daily payout but for a minimum of only 0.001 BTC balance. This will mean that everyone should be happier. High hashrate users will get only one payout daily and won't be spammed with several micropayouts. Low hashrate users will still get their payout every day. And I won't be holding that many of your Bitcoins in my hot wallet as every day almost whole balance will be paid out.

The payout model should change next week. I want to make significant changes in bulk and introduce them along with new user stats pages and after new servers are live and running. Something like CleverMining relaunch with more regional servers and lot of new things introduced.
hero member
Activity: 616
Merit: 522
I don't suppose anyone can explain why my account isn't paying out?  I'm at .027 ready to payout.  I've been over .02 for over a day and .01 for a couple of days.  I've triple checked my address number.  I asked once before, but it was at the end of a page and just before like two pages of reject complaints happened rapidly so I think it was overlooked : (

http://www.clevermining.com/users/1FLBnnF4MjBpH7vrRoarr8iFanYFoLBJG6 is me if it helps.

Your account is actually 1FLBnnF4MjBpH7vrRoarr8iFanYFolBJG6 as this is how you started mining. You then crrected it to 1FLBnnF4MjBpH7vrRoarr8iFanYFoLBJG6 but your account is created with the first form of username which you used, which has incorrect capitalization and isn't a valid Bitcoin address. Please send me a PM message and I will merge your accounts to the correct one when I'll be dealing with these issues (I have almost 10 people with similar issue and I'll make a script to solve these things automatically; please PM me so that I don't forget you - it's hard to remember something in the thread few pages back).
newbie
Activity: 3
Merit: 0
I don't suppose anyone can explain why my account isn't paying out?  I'm at .027 ready to payout.  I've been over .02 for over a day and .01 for a couple of days.  I've triple checked my address number.  I asked once before, but it was at the end of a page and just before like two pages of reject complaints happened rapidly so I think it was overlooked : (

http://www.clevermining.com/users/1FLBnnF4MjBpH7vrRoarr8iFanYFoLBJG6 is me if it helps.

Message Terk, he runs the mining pool. He will check it out and see what's wrong.
newbie
Activity: 9
Merit: 0
I don't suppose anyone can explain why my account isn't paying out?  I'm at .027 ready to payout.  I've been over .02 for over a day and .01 for a couple of days.  I've triple checked my address number.  I asked once before, but it was at the end of a page and just before like two pages of reject complaints happened rapidly so I think it was overlooked : (

http://www.clevermining.com/users/1FLBnnF4MjBpH7vrRoarr8iFanYFoLBJG6 is me if it helps.
legendary
Activity: 1318
Merit: 1040
Could you add an option to be paid only once per day?

I think the rest of us enjoy being paid more often.  I am sure Terk likes the security of it as well.  He does not have to hold large balances, just in case of attack.
+1

so %18 reject rate means still profitable?

I have 3.8% rejected for the last hour. Just mine for at least 24 hours and then check your "Last 24h Profits" stats. The amount of BTC there will answer your question for sure.
member
Activity: 117
Merit: 10
0.013btc/day per accepted MH/s
This is an important distinction.

--

Also there's a lot of poor and misguided advice on how the expiry, scan-time and queue settings actually influence the rejections you're experiencing.
A lot of these settings were made for HTTP communication and not the much more efficient stratum protocol*.

--expiry
This setting defines how long time it takes before a work share is declared stale.
It is not used on stratum servers, since stratum servers supply it with work shares.
Only exception is when the statrum server is broken, then the setting is used as a fallback value.

Recommendation: Leave at default setting. Server will supply a proper setting.

To verify above simply follow the opt_expiry variable in cgminer.c source file.

--scan-time
This setting defines how long time, in seconds, the client should spend scanning current active work.
Again a setting that is not used on stratum servers, since stratum servers supply it with work shares.
Only exception is when the setting is lower than the server supplied setting, then it'll potentially generate more stale work.

Recommendation: Leave at default setting, which is 30 seconds for scrypt.

To verify above simply follow the opt_scantime variable in cgminer.c source file.

--queue
This setting defines how many work items you minimum got waiting in queue.
It is only relevant to prevent downtime when the stratum server is too slow at serving new work shares.

Recommendation: Leave at default setting, which is 1.

To verify above simply follow the opt_queue variable in cgminer.c source file.

* Stratum mining protocol: http://mining.bitcoin.cz/stratum-mining and https://bitcointalksearch.org/topic/ann-stratum-mining-protocol-asic-ready-108533


Ok if this is right why i get 35% more WU and half of the reject rate when i change the default values to other values ?

How long did you test your WU? At least several MHash/s over the course of >12 hours I assume, otherwise surely you wouldn't be so confident in your findings? And for the rejects, certainly you tested two otherwise identical rigs at the same time?
newbie
Activity: 51
Merit: 0
so where you get your information the stratum server gives the parameter to the client....and especially the clevermining server will do so ?

I get my information straight from the source code.

If you open util.c and find the function named json_rpc_call(), there's a parameter named rolltime. That is an outgoing parameter is set by a server-side value from the JSON RPC.
Now back to cgminer.c, where you can then follow "work->rolltime" around in the code and see how it's being compared to both the expiry setting and scan-time setting and in both cases, the server-side value is chosen over the local setting as long as it is largest.

This is all based on the source code, but I have of course also tested the settings with different values myself and I found no measurable differences.
sr. member
Activity: 490
Merit: 250
I have some amount of Unexchanged balance, since 3days ago.

When they gonna be exchanged?
sr. member
Activity: 378
Merit: 250
so %18 reject rate means still profitable?
full member
Activity: 158
Merit: 100
@Kalroth its nice to get some information  from people much closer to the source....

------------schnipp-------------
Stratum: the server gives the client templates that the client can use to generate its own work. Only the block header and first transaction (generation transaction) are included. Stratum uses the least bandwidth of all the protocols. Stratum also makes it very fast and efficient to switch to new work data when there is a block change, which can help keep down the reject ratio caused by stale work. Unlike the other protocols it is not HTTP, so it won't work over an HTTP proxy. There is no real specification. There is a document that explains the core features and for the rest you have to read the source code for "stratum mining proxy".

--------------schnapp------------------

so where you get your information the stratum server gives the parameter to the client....and especially the clevermining server will do so ?

I'am confused..... Huh because the default settings as i mentioned before are so much worser then the hints and tipps i found round the world



jr. member
Activity: 37
Merit: 1
Could you add an option to be paid only once per day?

I think the rest of us enjoy being paid more often.  I am sure Terk likes the security of it as well.  He does not have to hold large balances, just in case of attack.
newbie
Activity: 51
Merit: 0

Ok if this is right why i get 35% more WU and half of the reject rate when i change the default values to other values ?

http://en.wikipedia.org/wiki/Correlation_does_not_imply_causation.

I'd like to see if anyone else here gets 35% higher WU and half their reject ratio just by changing the default settings. Or to reverse it, if people get a 35% lower WU and double the reject ratio by using the default settings. Because those values sound a little suspicious to me - but seeing as I know nothing about your setup or testing methodologies, I can't really refuse them.
full member
Activity: 208
Merit: 100
0.013btc/day per accepted MH/s
This is an important distinction.

--

Also there's a lot of poor and misguided advice on how the expiry, scan-time and queue settings actually influence the rejections you're experiencing.
A lot of these settings were made for HTTP communication and not the much more efficient stratum protocol*.

--expiry
This setting defines how long time it takes before a work share is declared stale.
It is not used on stratum servers, since stratum servers supply it with work shares.
Only exception is when the statrum server is broken, then the setting is used as a fallback value.

Recommendation: Leave at default setting. Server will supply a proper setting.

To verify above simply follow the opt_expiry variable in cgminer.c source file.

--scan-time
This setting defines how long time, in seconds, the client should spend scanning current active work.
Again a setting that is not used on stratum servers, since stratum servers supply it with work shares.
Only exception is when the setting is lower than the server supplied setting, then it'll potentially generate more stale work.

Recommendation: Leave at default setting, which is 30 seconds for scrypt.

To verify above simply follow the opt_scantime variable in cgminer.c source file.

--queue
This setting defines how many work items you minimum got waiting in queue.
It is only relevant to prevent downtime when the stratum server is too slow at serving new work shares.

Recommendation: Leave at default setting, which is 1.

To verify above simply follow the opt_queue variable in cgminer.c source file.

* Stratum mining protocol: http://mining.bitcoin.cz/stratum-mining and https://bitcointalksearch.org/topic/ann-stratum-mining-protocol-asic-ready-108533


Ok if this is right why i get 35% more WU and half of the reject rate when i change the default values to other values ?



I suspect as per Terks comments (custom stratum software) we are running a stratum server that doesn't conform to the stratum protocol standard.

Good news tho after 3 and 1/2 hour reject is at 2.6% and 0% stales. Hash is 750khsec and WU is 675 shares/min.
full member
Activity: 158
Merit: 100
0.013btc/day per accepted MH/s
This is an important distinction.

--

Also there's a lot of poor and misguided advice on how the expiry, scan-time and queue settings actually influence the rejections you're experiencing.
A lot of these settings were made for HTTP communication and not the much more efficient stratum protocol*.

--expiry
This setting defines how long time it takes before a work share is declared stale.
It is not used on stratum servers, since stratum servers supply it with work shares.
Only exception is when the statrum server is broken, then the setting is used as a fallback value.

Recommendation: Leave at default setting. Server will supply a proper setting.

To verify above simply follow the opt_expiry variable in cgminer.c source file.

--scan-time
This setting defines how long time, in seconds, the client should spend scanning current active work.
Again a setting that is not used on stratum servers, since stratum servers supply it with work shares.
Only exception is when the setting is lower than the server supplied setting, then it'll potentially generate more stale work.

Recommendation: Leave at default setting, which is 30 seconds for scrypt.

To verify above simply follow the opt_scantime variable in cgminer.c source file.

--queue
This setting defines how many work items you minimum got waiting in queue.
It is only relevant to prevent downtime when the stratum server is too slow at serving new work shares.

Recommendation: Leave at default setting, which is 1.

To verify above simply follow the opt_queue variable in cgminer.c source file.

* Stratum mining protocol: http://mining.bitcoin.cz/stratum-mining and https://bitcointalksearch.org/topic/ann-stratum-mining-protocol-asic-ready-108533


Ok if this is right why i get 35% more WU and half of the reject rate when i change the default values to other values ?

member
Activity: 84
Merit: 10
Could you add an option to be paid only once per day?
newbie
Activity: 3
Merit: 0
Any idea when vardiff is coming back?  This 512 difficulty is killing me when we hit a low difficulty (7-8) coin.  I don't get any accepted shares.
newbie
Activity: 45
Merit: 0
On rejection complaints:

Most, if not all of rejection complaints are coming from people with little to no experience in mining.  Hashing Xmh/s doesn't make you experts at mining, it just mean you have much $$ to throw around.

What you all fail to understand is that mining has MANY variables and you can't just implement 1 setting to all pools.  Here @ CM, fast coins are mined as SAID MANY TIMES BEFORE.  That means you need to make adjustments in your config file to make it suitable. It's NOT ONE SIZE FITS ALL.

Here's my suggestion: Read up and understand how mining works.  Yes, that means study it.  In this instant gratification world, I know it's something hard to do, but that's what it takes.  Otherwise your rejection will continue to be high.  Guess what?  It's your own damn fault.  Many good suggestion were posted in this thread, but obviously you all are too lazy to look it up OR understand how it works.

Since the fix implementation of about week ago, Terk has done what he could to bring rejections down.  I have less than 5% rejection running for good week now.  Experienced miners already made the changes and are doing just fine.  Newbs are ones that can't grasp this concept.


On server complaints:

Have patience.  

Have a nice day.

I've seen this response almost every time someone asks about rejects.  It's basically "blah blah blah, you need to learn about mining and making changes to your config, but I'm not going to provide you with any other information it's secret to me you're too new blah blah blah".

It's getting tiring.  A few people have suggested adjustments to queue length, scan time and expiry time - and others explained why increasing or decreasing would have an impact on multipool vs. standard coin (this was great advice).

What other advice can we share to tweak our configs?  (instead of hoarding it).

Having a great time ryan? its amazing no other pools have probs

I am actually - this pool is making me a killing compared to every other I've tried.  I've actually been really positive on these forums!
Jump to: