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

[Kalroth]

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.

For what it's worth, my Linux rig with 280Xs is currently sitting at a 3.15% reject rate - with all three settings at default.
My Windows rig with 290s is over double that, at ~8% in the same time span and from the same connection - also with all three settings at default.

On Wafflepool I saw around 0.5% on the 280X rig and ~1-2% on my Windows rig. On a regular non-switching mining pool those numbers are cut in half, nearly zero on the 280X rig and below 1% on my Windows rig. With the exact same settings that gives me 3-8% on this pool.

I'm not entirely certain why there is a difference between the two systems, but I suspect the issues may lie within the differences between both OS' TCP configuration. At least I know there's been issues with Windows and it's TCP implementation previously. There's also been several fixes* for online games previously, another genre that also requires a fast and stable internet connection. Note that this last paragraph is just a wild guess on my part - I'm merely curious and raising the question, I haven't done any leg work yet.

* http://www.sk-gaming.com/content/15500-Smart_fix_allows_you_to_drop_your_ping_by_150
* http://www.justanswer.com/computer/3du1a-rid-200ms-delay-tcp-ip-ack-windows.html

[Prima Primat]

..

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.

It's literally impossible to judge how these settings perform (or rather, whether or not they have any impact at all) by trying them on different days. The pool's reject rate varies heavily, right now the average is ~5%, but if we mine faster coins again or the pool's hashrate grows, we might get 10% or 15% tomorrow. And then you'll say "Kalroth is wrong, these settings suck"

[CoinBuzz]

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

So the server (@Terk) need to tweak these settings ?

[Kalroth]

So the server (@Terk) need to tweak these settings ?

I don't know the inner workings of Terks pool setup, it is likely be something entirely else. There is a lot of work going on behind the scenes; multiple coin stratum servers with a proxy redirecting people to the right internal server, adjusting worker count based on coin difficulty, storing share results, importing exchange trades, etc. etc. I've got very little experience when it comes to the actual operation of a mining pool, so all I really can do is to make a bunch of assumptions and that won't help anyone.

All I do know is that Clevermining gives me a higher reject ratio than anywhere else and there isn't much that I can do about it on my side. But in the end it's the payouts that matter. :)

[ratty]

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.

A bunch of us have done that on this subreddit: http://www.reddit.com/r/multimining
I did wafflepool vs middlecoin for 5 days and wafflepool came out ahead.
Also there is this site: http://poolpicker.eu/ (he talks about how he gets those stats on his twitter https://twitter.com/Webbson_/ )
That website gets its data from the pool's reported stats, so you would have to trust the pools not to pad their stats.
I might split my GPUs up between clevermining and another pool, but several of these pools look the same when looked at on the long term, I'm not sure if it matters.

So yeah, ignore rejects, all that matters is how much Bitcoins get into your wallet over the long term.

[Terk]

Hi, I'm new here.

I've been mining from the pool for about five days, and I've been above .01 payable for a couple of days.  I'm at .023 payable now (I only run ~800 KH/s to give you an idea of time it'd take to get that high).  I haven't had a payout on the account though.  Wondering if somethings going on? I doubled checked my address and it's correct.

It's most likely because your address isn't correct in the end. You might started mining with an incorrect address (e.x. one lowercase letter in place of uppercase) and later corrected it, but your username was created with wrong capitalization and the first/original username is the address which is tried for withdrawals.

PM me with your username and I will check.

[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.

A bunch of us have done that on this subreddit: http://www.reddit.com/r/multimining
I did wafflepool vs middlecoin for 5 days and wafflepool came out ahead.
Also there is this site: http://poolpicker.eu/ (he talks about how he gets those stats on his twitter https://twitter.com/Webbson_/ )
That website gets its data from the pool's reported stats, so you would have to trust the pools not to pad their stats.
I might split my GPUs up between clevermining and another pool, but several of these pools look the same when looked at on the long term, I'm not sure if it matters.

hmm... it's a good start, I guess, although I'm curious to actual payouts instead of self-reported payouts at poolpicker, since "accepted hashrate" is an important variable between pools that should be part of the comparison.

[tengattack]

hi, when will the asia sever go up?

[Terk]

I know a lot of people are very impatient waiting for EU and Asia servers. There were just too many things going on which made me to work on them instead of the new servers. I saw some market conditions and decided that we can take advantage. Today's profitability is the result of this and lots, really lots of manual trades which I've been doing in between fighting DDOS and optimizing servers. I didn't even have time to chat here or on IRC channel.

Just wanted to let you know that I'm here working almost 24/7 on what appears to have the biggest priority at any given moment. In the last 24 hours DDOS and manual trading opportunities were more important to deal with than launching new servers and so they got my attention. I'm back to working on new servers now.

[ebliever]

I just want to thank Terk for all his hard work. After trying CM over and over and seeing rejects go sky high, I'm finally running stable for a long while at <7% rejects and a very strong hash rate. Thanks again for your efforts!

[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.

It's literally impossible to judge how these settings perform (or rather, whether or not they have any impact at all) by trying them on different days. The pool's reject rate varies heavily, right now the average is ~5%, but if we mine faster coins again or the pool's hashrate grows, we might get 10% or 15% tomorrow. And then you'll say "Kalroth is wrong, these settings suck"

With the settings used for the past few days, I've been below 5% which was way below the pool hash rate of 10%~. You are right, so I just expect to fall below the pools reject rate. If I find performance is worse ie over the pool hash rate, that indicates to me the settings have some affect and I'll go back to use them. As results proof to me they have an affect with this pool and so the stratum protocol in use is not following the standard based on Kalroths comments and my results.

Just read Kalroth's responses, interesting that he believes its the pool at fault since there is no more tweaking to be done on my end. Also reject rate does matter as its the accepted rate that is paid. So if I get a really large reject rate it will negatively affect my earnings.

I already have the tcp fix installed, I used this on Win7: http://www.wowinterface.com/downloads/info13581-LeatrixLatencyFix.html

[ryancpwalsh]

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!

[PopeFrancis]

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.

[igroock]

Could you add an option to be paid only once per day?

[nowaltcoin]

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

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 ?

[pengoau]

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

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.

[Kalroth]

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.

[jasdace]

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.

[nowaltcoin]

@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..... because the default settings as i mentioned before are so much worser then the hints and tipps i found round the world

[ozzy1926]

so %18 reject rate means still profitable?