unless we are just getting extremely lucky, i'd say @terk's profitability tweaks are working pretty well...

http://i.imgur.com/4wFIErb.png

On rejects...

FWIW, I finally went ahead and dialed down my Intensity this morning a little bit to see what the effect would be on rejects. I had been running intensity at 21 which maxed my hashpower. I dropped down to 19 and the effect on hashpower was a loss of roughly 5%. After a few hours of running @19, reject percentage seems to have dropped by 2/3 (from close to 15% to around 5%) and from being consistently well above the poolwide reject % to being consistently at or below it.

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.

bummer on the DOS.

profitability kicking some serious ass.

what you see on the site for the hashes is an hour avg. so if you've been failed-over for part of that hour, it's averaging in 0 for that period and it makes the number look smaller.

If not aware, the most interesting development in cgminer forks for scrypt is happening HERE. With discussion HERE.

I don't mean to be rude, but discussions of UK electricity rates and decorative koi are not a little off-topic in a thread dedicated to the operations of a specific mining pool.

The information value of a thread in a forum such as this -- especially one as long as this one is -- is directly related to how tightly focused it stays on its topic.

There are any number of excellent venues for side conversations that wouldn't detract from the value of this thread.

totally agree on this. it would be good to eliminate single points of failure where possible, and putting all the exchange in one basket seems like a bad concentration of risk. i've had good experience with vircurex.

since the server update (nice work, @Terk), rejects (which for me were already pretty low) are a lot lower. but for the first time i am seeing the:
which several people have been reporting. this does not seem to be affecting my rejected percentage as far as i can tell. sgminer definitely does not think it is.

i am also getting a very large number of stales accepted. does this seem weird?:
http://i.imgur.com/pJucpz7.png

Also seeing disconnects from US and failover to backup pools this morning (US morning). I wonder if the increase in miner numbers / hashrate is stressing the server, or if there might be a (hopefully transient) network issue at the provider?

It's negligible compared to the statistical variance of mining luck over the time period measured. If that difference persisted for months, then for sure not negligible. But over a period of three days it is pure statistical noise and doesn't say anything conclusive one way or another.

that's a total misunderstanding of how the mining process works. every share you calculate takes (roughly) the same amount of time to calculate. your GPU's are churning through hashes as fast as they can and only submitting the ones that are "better" than the current difficulty. each one takes just as long as the one before and the one after to calculate, but only some of them are better than the current difficulty. it doesn't take any longer to calculate them - the difficulty just makes it less likely that any given calculated share will be good enough to submit.

the reason we are all so keen to have our GPU's have higher kHash rates is not because that makes them calculate a given share faster, it's because it measures how many shares they can spew out every second.

Satoshi spam. Hitting many wallets. Some details here and here.

Would be nice if Multibit had a way to control inputs for send transactions which would let advanced users deal with the spam.

this "satoshi spam" has nothing directly to do with CM. see here.

I don't know what's up with people getting so many rejects. This is after running for 12 hours or so:

http://i.imgur.com/0A9oR6D.png

here's my settings (running sgminer 4.1.0-15-gbe43):

My guess is that in the long run, best profitability would come from selling the currently most profitable alt (what you are mining at the time) for btc as close to as soon as you mine it as possible (taking into account appropriate batching to minimize fees) - UNLESS there is a long enough, unavoidable delay in being able to transfer and execute those sales. "Long enough" in this case being relative to the exchange rate volatility. In that case, if the delay is unavoidably long, then using some judgement (say in the case of a sudden, rapid and unexplained drop in value of alts you just mined and haven't yet exchanged) would probably yield better results than a slow, automatic system.

Speaking of unexchanged...

Besides getting the pool running smoothly and having the best algorithm for mining the right coin at a given time, I imagine that the mechanics of actually exchanging alts for btc's is going to be the biggest variable in profitability. The exchange rates are so volatile, I imagine that efficiency of getting the mined alts to an exchange and trading them for btc while they are still "hot" has to be a huge issue.

Is there any way to maximize efficiency in this area that you are not already taking advantage of, @Terk? Using multiple exchanges, automating transfers and sales of alts? Or is there no way to automate this stuff and it just has to be done by hand?

FWIW, just as an alternate opinion on this issue, I don't require any of this kind of transparency at all to point my hashes at clevermining. I also don't need a well-designed website. I have hashed at middlecoin and at wafflepool and their pedestrian websites don't put me off at all. I do not care what coin the pool is mining at any given time. I really only care about maximizing my profit and I don't need @Terk to tell me how he is doing that as long as he is actually doing it. I also don't care what his fees are. If his fees are literally 5 times higher than the fees at middlecoin or wafflepool, but I am still banking more coin to my wallet, then I am happy to pay those fees. In my reality, there is no such thing as "fair" fees. If @Terk figures out how to get me more coins for my hashrate than I can get elsewhere, then he can charge me whatever he wants to put more coins in my wallet than I can get elsewhere.

The only transparency that I need is as follows:

1. The indisputable and irreversible BTC deposits into my wallet should match up with the claimed stats on the website
2. Nobody else who is mining at the pool should be reporting discrepancies in what they are actually being paid

For me, the reason that I am currently hashing at clevermining is that from the care of design of his website and from his responsiveness in this thread, I believe that @Terk is putting in a good-faith effort to create a more profitable pool and based on the quality of his work that I have seen so far, I think it is possible/probable that he may be better at it than others. But I will switch to another pool as soon as I don't believe that anymore.

So far, for me the results are still inconclusive. On the plus side the reported history of profitability looks to me a bit better than middlecoin and a fair bit better than wafflepool, though I don't think there is enough history yet for that to be conclusive. My own experience is that my daily earnings at clevermining have been roughly on par with my daily earnings at middlecoin - within the statistical noise that mining is. But that is also not conclusive to me because I haven't mined long enough at either pool to get past the statistical noise.

I'm not saying that you are not correct for yourself and others requiring the kind of transparency that you are asking for in order for clevermining to gain more hashers. You might be totally right about that. I'm just saying that that is not true for me. Given the ease of pointing one's miner at another pool at a moment's notice, I just utterly fail to see how @Terk could possibly be taking advantage or scamming anyone. As long as the payouts are hitting miner's wallets, I just don't see any space available for ripping anyone off. And obviously the moment the payouts are not happening, or are not competitive, it will be completely obvious to everyone and there will instantly be no more clevermining.

At absolute BEST, @Terk might be able to walk away with one day's take before everyone left. My guess is not even that. And given what he has obviously invested in sweat so far, my judgement is that he has much more financial incentive to make the results as competitive as possible and pull in his percentage for the long haul.

That's my 2c.

@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?

http://i.imgur.com/IPdKojI.png

also seeing pretty high ratio of unexchanged coins in my account.

yeah, WTF?

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

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

@Terk, i think you should fix this.