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

[pengoau]

For what its worth I'm sitting on 3% rejects (rejects+stales) with my most recent settings and a WU of 665 shares/min. This is what I am sitting on after 18hrs of mining.

I'm in Australia with just an adsl2+ connection (not great but ok).

   What ping do you have?

No doubt due to ddos protection ping replies is disabled, so pinging us.clevermining.com resluts in "request timed out".

[element515]

Quick question, my one miner seems to occasionally lose Internet connection or switch to my fail over. It gets stuck however when reconnecting and just stops doing anything. Is there a setting I can add to restart the program if it doesn't do anything for a while?

same thing here , any command line option ? be much appreciated

CGWatcher? works good for me, restart miner/computer if needed

Will this work with SGMiner?

[martynw2000]

0.013btc/day per MH/s

^ Exactly


What else matters?

[ozzy1926]

Do the k/hash rate change from pool to another pool?Because i was getting 910k/hash from europe.mine-litecoin.com and today switch to this and gettiing 840k/hash.

[dency45]

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 tweaked a lot. Even tried intensity 8 still high reject percentage 30%+ but it's okay i am still getting 0.009 - 0.01 per day.

[mishak]

I have zero rejects. I just clear statistics each second

On more serious note. Is the address[_worker] feature available? There is no mention of it on the page. But I saw one post here mentioning it. Does it group workers under address overview too?

[FoFFiFFe]

0.013btc/day per MH/s

^ Exactly


What else matters?

http://feb.imghost.us/JPGX.png

I'm joking ...   

[pengoau]

Quick question, my one miner seems to occasionally lose Internet connection or switch to my fail over. It gets stuck however when reconnecting and just stops doing anything. Is there a setting I can add to restart the program if it doesn't do anything for a while?

same thing here , any command line option ? be much appreciated

CGWatcher? works good for me, restart miner/computer if needed

Will this work with SGMiner?

Try it and find out, is it so hard?

Do the k/hash rate change from pool to another pool?Because i was getting 910k/hash from europe.mine-litecoin.com and today switch to this and gettiing 840k/hash.

https://bitcointalk.org/index.php?topic=448649.msg5424508#msg5424508

People aren't obviously reading or doing their research, is it a wonder why I'm so cranky.

[zneww]

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

[radiumsoup]

You know, the best way I see to put this reject difference between pools stuff to bed would be a simple test: given two identical optimized rigs (largish ones to help combat variance) with identical configurations, each pointed to a different pool, run them for exactly the same amount of time for at least one week. Compare total payouts. Best payout wins.

I may do that this weekend (I'll have to do some calculations on power draws first when switching things around to make identical setups though - back of the napkin math says should work at ~2.5M/h each for the two older rigs I have in mind for rearranging for this) unless someone else is already doing this and wishes to share with the class

[pengoau]

You know, the best way I see to put this reject difference between pools stuff to bed would be a simple test: given two identical optimized rigs (largish ones to help combat variance) with identical configurations, each pointed to a different pool, run them for exactly the same amount of time for at least one week. Compare total payouts. Best payout wins.

I may do that this weekend (I'll have to do some calculations on power draws first when switching things around to make identical setups though - back of the napkin math says should work at ~2.5M/h each for the two older rigs I have in mind for rearranging for this) unless someone else is already doing this and wishes to share with the class

Have to run them at the same time to rule out market fluctuations, if this isn't already known.

[pjv]

TL;DR try to get your rejects as low as possible for a given pool. Don't compare reject % from one pool to another pool.


Optimizing reject percentage makes sense in order to get the best results you can with your setup on a given pool. Do whatever you can to bring rejects down as low as you can FOR A GIVEN POOL.

Comparing your reject percentage from one pool to another pool (especially coin-switching pools) makes absolutely no sense whatsoever. As soon as you say something like, "my rejects at CM are much higher than my rejects at _____", then you are focusing on the wrong issue and there is never going to be a satisfactory answer.

The only thing that makes sense to compare from one pool to another pool (aside from support / aesthetic / personal stuff) is what is your profitability at pool X vs. pool Y with your rig optimized for each.

If your rejects are 50% at CM and 3% somewhere else, but you are still more profitable at CM even with the 50% rejects, then it's an error to 1. complain about the high rejects by comparing them to somewhere else, and 2. mine somewhere else merely because you think that it is bad to have high rejects.

[Kalroth]

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 http://bitcointalk.org/index.php?topic=108533.0

[Alpharoid]

You're Kalroth???    Boy thanks for the advice! 

[zneww]

You're Kalroth???    Boy thanks for the advice! 

Yes, the Kalroth just educated you guys

[radiumsoup]

You know, the best way I see to put this reject difference between pools stuff to bed would be a simple test: given two identical optimized rigs (largish ones to help combat variance) with identical configurations, each pointed to a different pool, run them for exactly the same amount of time for at least one week. Compare total payouts. Best payout wins.

I may do that this weekend (I'll have to do some calculations on power draws first when switching things around to make identical setups though - back of the napkin math says should work at ~2.5M/h each for the two older rigs I have in mind for rearranging for this) unless someone else is already doing this and wishes to share with the class

Have to run them at the same time to rule out market fluctuations, if this isn't already known.

Yes, exactly - which is why I said there should be two identical rigs (I suppose I didn't specify "running simultaneously", although that was my intent)

[elpsycongro]

We just got kalroth'd  
I figured out this pool will have high rejects and after 2 weeks i learned what is normal and honestly it hasnt affected my payouts so i can live with 8% rejects and yes my rig is optimize for my needs.

[Th3P]

People find the payouts better or worse than TradeMyBit?

[scryptographer]

You know, the best way I see to put this reject difference between pools stuff to bed would be a simple test: given two identical optimized rigs (largish ones to help combat variance) with identical configurations, each pointed to a different pool, run them for exactly the same amount of time for at least one week. Compare total payouts. Best payout wins.

I may do that this weekend (I'll have to do some calculations on power draws first when switching things around to make identical setups though - back of the napkin math says should work at ~2.5M/h each for the two older rigs I have in mind for rearranging for this) unless someone else is already doing this and wishes to share with the class

Have to run them at the same time to rule out market fluctuations, if this isn't already known.

Yes, exactly - which is why I said there should be two identical rigs (I suppose I didn't specify "running simultaneously", although that was my intent)

See this thread for a comparison of 5 switching pools
https://bitcointalk.org/index.php?topic=456564.0

[pengoau]

..

You are more knowledgeable than me. I've removed the settings and restarted the miner, after 18hrs using the settings I'm at 3.5% reject. Shall be interesting if I'm around 3.5% after 18hrs with the settings removed.

If not the server may not be compliant with the stratum protocol. Terk has stated it runs its own version of stratum, so I guess we will see (if the settings are required for his servers).

Proof will be in the pudding? I run sgminer 4.1 with the zuikkis kernel fwiw.