[ANN] profit switching auto-exchanging pool - www.middlecoin.com

[Prelude]

I love the idea of this pool, and have been using it with ~17-18MH/s for the last 2 days. I don't have any time to manage my miners these days, so this is a perfect solution.

That being said, the issues listed above are a problem which I've also noticed.

My setup looks something like this:

7970s mining @ 800KH/s
7970s mining @ 740KH/s
7950s mining at 655~680 KH/s

Everything works great for the most part, except when the pool switches to low difficulty and or low block time coins. Right now, the pool is mining what I assume to be Litecoins because of the 54.9M difficulty level. When we're mining high difficulty coins like this, everything is fine and all of my cards are able to submit shares @ 512 difficulty since we're working on those 54.9M difficulty blocks for long enough. In this case, 512 difficulty shares are perfect.

The problems start when we switch to less than 50~100k difficulty or so coins, from what I've noticed. 512 difficulty shares simply take too long to calculate, and new blocks are discovered before 90% of us have a chance to even submit a single share. This means that we are (mostly) all burning electricity and wasting time for absolutely nothing, as only the 10% (in this made up example) of the pools users are managing to submit shares/blocks while the rest of us get nothing due to the 512 difficulty setting.

The solution to this is very simple, thankfully. We need lower difficulty, 128 or max 256 difficulty shares. Unfortunately, this causes problems for the pool operator since it's increasing the work load on his server.

A better, but harder solution which may or may not be possible for the server:

Coin difficulty >500k = 512 share difficulty
Coin difficulty >200k = 256 share difficulty
Coin difficulty >100k = 128 share difficulty
Coin difficulty >50k = 64 share difficulty
Coin difficulty <50k = 32 share difficulty

I think this would optimize profits for everyone, including the pool operator who would end up collecting more fees off of our higher individual profits received from submitting low difficulty shares on super fast coins which are currently escaping us.

Thankfully I've got quick mining cards. I can only imagine how much worse the problem must be for people mining on 6 and 5 series cards.

h20, you've been doing a stand up job managing and tweaking the pool. You deserve more than all the profits you've been making so far from the 3% fee. Lower the share difficulty, and you'll have just that. 

Thanks for running this awesome pool, and I really hope this small problem gets resolved when you have the time so that myself and others can continue mining with you. 

[h2odysee]

Unfortunately, another bad payout. 0.0293 BTC per MH/s per day.


The coins we switch to that have low difficulty are in fact more profitable. Even with the high reject rate, sometimes as much as 70%.

The people who benefit from these coins most are those with low reject rates. Not those with high hashrates.

Well that was odd. I had .03 BTC confirmed a bit ago and now down to .027 when I refreshed again.

JR

That should never happen. What is your address?

[Prelude]

The coins we switch to that have low difficulty are in fact more profitable. Even with the high reject rate, sometimes as much as 70%.

The people who benefit from these coins most are those with low reject rates. Not those with high hashrates.

High hash rates and luck lead to lower rejects, while ping also plays a smaller factor. The smaller miners (5xxx and 6xxx cards) get crushed with these coins, while fast cards don't fare all that much better with 512 difficulty coins.

If I'm misunderstanding something, I apologize. I'd appreciate an explanation to understand properly, though.

[h2odysee]

The switcher had been stuck on litecoin for 2 hours prior to the payout today. Sorry about that.

... rejected hashrate skyrockets. In addition, after that happens, my accepted and my rejected hash rate added together do not equal my total hashrate, and they should.

I have been noticing that as well. When the reject rate increases, the total hashrate drops. At first I was thinking it was that people were using --no-submit-stale, but that shouldn't account for that much hashrate loss.

High hash rates and luck lead to lower rejects, while ping also plays a smaller factor. The smaller miners (5xxx and 6xxx cards) get crushed with these coins, while fast cards don't fare all that much better with 512 difficulty coins.

If I'm misunderstanding something, I apologize. I'd appreciate an explanation to understand properly, though.

Yeah, I think you're right about 5xxx and 6xxx cards getting more reject rates. So they are hurting.

But also, the people on the top end are hurting too. They are losing out on profits they could have had if we had switched to high block rate coins more often. The people doing the best are in the middle, because I average the stats when choosing coins.

I've talked way too much about difficulty in this thread. It doesn't play a factor.

[h2odysee]

We can be "autoswitching into dud coins" because it is very possible that coins look very nice on paper (theoretically the most profitable) but in practice it could not be the most profitable, even by a long shot. The whole point of this pool is indeed to attempt to switch to the most profitable but perhaps some real-world conditions are coming into play that are not taken into account when calculating the most profitable coin on paper

There are some real world factors I don't take into account very well. One is that when we switch, we lose out on a few seconds of hashing. I've "tweaked" some specific coins to adjust for this, as to not switch as often to coins that are only going to be mined for 10 seconds then switch back.

Also, I'm sure it's the case that having that gap while switching is putting wear and tear on GPU fans, and creating system instability.

The real solution is to eliminate the gap.

[Prelude]

I've talked way too much about difficulty in this thread. It doesn't play a factor.

Are you sure about that? I know that 16x 32dif shares will pay out the same as 1x 512dif share, but when we hit those blocks that simply fly by without any solved shares wouldn't it be better to get a few 32dif shares in? Or is it simply about solving blocks at that point making shares irrelevant?

Sorry if this has been discussed already, I haven't had time to read this entire thread.

[h2odysee]

Are you sure about that? I know that 16x 32dif shares will pay out the same as 1x 512dif share, but when we hit those blocks that simply fly by without any solved shares wouldn't it be better to get a few 32dif shares in? Or is it simply about solving blocks at that point making shares irrelevant?

Sorry if this has been discussed already, I haven't had time to read this entire thread.

If blocks come frequently, that doesn't make high difficulty shares any less likelier.

It increases your reject rate, but it does so equally for high difficulty shares and low difficulty shares.

[Prelude]

We can be "autoswitching into dud coins" because it is very possible that coins look very nice on paper (theoretically the most profitable) but in practice it could not be the most profitable, even by a long shot. The whole point of this pool is indeed to attempt to switch to the most profitable but perhaps some real-world conditions are coming into play that are not taken into account when calculating the most profitable coin on paper

There are some real world factors I don't take into account very well. One is that when we switch, we lose out on a few seconds of hashing. I've "tweaked" some specific coins to adjust for this, as to not switch as often to coins that are only going to be mined for 10 seconds then switch back.

Also, I'm sure it's the case that having that gap while switching is putting wear and tear on GPU fans, and creating system instability.

The real solution is to eliminate the gap.

If anything it's giving the fans a few seconds of rest, I wouldn't worry about that. I don't see why temporarily dropping the GPU load while switching would cause instabilities by it's self. It would be a coincidence for a system to crash at the same time, it would've eventually crashed on it's own without the coin switch.  

[Prelude]

Are you sure about that? I know that 16x 32dif shares will pay out the same as 1x 512dif share, but when we hit those blocks that simply fly by without any solved shares wouldn't it be better to get a few 32dif shares in? Or is it simply about solving blocks at that point making shares irrelevant?

Sorry if this has been discussed already, I haven't had time to read this entire thread.

If blocks come frequently, that doesn't make high difficulty shares any less likelier.

It increases your reject rate, but it does so equally for high difficulty shares and low difficulty shares.

Ah, right. That makes sense. I was thinking that if I managed to submit a 32 dif share, the next person's 32 dif share might be the block solver whereas with 512 dif shares neither of us would've managed to submit a share. Sorry about the misunderstanding.

[503guy]

When the reject rate increases, the total hashrate drops. At first I was thinking it was that people were using --no-submit-stale, but that shouldn't account for that much hashrate loss.

I've talked way too much about difficulty in this thread. It doesn't play a factor.

Hash rate drop

• Assume 100 miners connected to pool.  They are always connected and always hashing.
• Pool switches to low diff coin (all miners still connected)
• Miners start to get "new block" "new block" "new block" (in my experience this can go on for 10 minutes without submitting a share)
• Hash rate on pool drops (not because miners aren't mining -- they just can't submit shares fast enough prior to a block change)

That's my interpretation of why there is a hash drop.

I have 4 7950s connected to your pool, they generally hum along between 2.4mhs - 2.6mhs on a LTC pool.  Here, on the pool side by hash rate has been consistently reported as 1.9-2.1mhs.  The only thing I can attribute that to from what I see on my end is the "new block new block new block" for 10 minutes without being able to submit a share, therefore to the pool it doesn't look like I'm mining.

Just my two cents, I wanted to continue to beat the dead horse.  I think share difficulty has everything to do with it, but I'm of a layman viewpoint.  Thanks for your hard work and I hope to see this pool get better. 

[cryptopi]

Unfortunately, another bad payout. 0.0293 BTC per MH/s per day.


The coins we switch to that have low difficulty are in fact more profitable. Even with the high reject rate, sometimes as much as 70%.

The people who benefit from these coins most are those with low reject rates. Not those with high hashrates.

First, your pool idea (auto conversion to bitcoins) is great. I's like to see you get as much traffic as possible to reward your efforts.

I appreciate that you believe that they "are in fact" more profitable (I'm sure under some scenario they are), that's just not the results that I and a lot of others experience. After all results are considered, the net result is certainly very low profit for me, with ample evidence. The data is very clear. I'm not complaining about a high reject rate; I'm complaining about poor mining results. My reject rates seem typical for the pool, and yes everyone's rates go up when these coins get mined. I'm concerned about results, not rejects (they are just a symptom).

I submit to you that the lower payouts you notice on the pool overall have a lot to do with this problem. I have spent many hours studying the pool results, minute(s) by minute(s), during the mining of the various coins, and absolutely see a strong correlation. Please consider this a real problem, even though you seem to believe that it is not. I want to stay in your pool, but this makes it much less economical.

[h2odysee]

I appreciate that you believe that they "are in fact" more profitable (I'm sure under some scenario they are), that's just not the results that I and a lot of others experience.

...

 I have spent many hours studying the pool results, minute(s) by minute(s), during the mining of the various coins, and absolutely see a strong correlation. Please consider this a real problem, even though you seem to believe that it is not. I want to stay in your pool, but this makes it much less economical.

I definitely want to look at it.

A major flaw right now in the pool, and one that I'm currently working on, is proper reporting. While the math says that a certain coin is more profitable, I don't have any easy way to tell for sure, other than doing painstaking manual database lookups.

What I really need is a profit graph. Then I can see where it dips, and what coin we were at then.

[cryptopi]

I appreciate that you believe that they "are in fact" more profitable (I'm sure under some scenario they are), that's just not the results that I and a lot of others experience.

...

 I have spent many hours studying the pool results, minute(s) by minute(s), during the mining of the various coins, and absolutely see a strong correlation. Please consider this a real problem, even though you seem to believe that it is not. I want to stay in your pool, but this makes it much less economical.

I definitely want to look at it.

A major flaw right now in the pool, and one that I'm currently working on, is proper reporting. While the math says that a certain coin is more profitable, I don't have any easy way to tell for sure, other than doing painstaking manual database lookups.

What I really need is a profit graph. Then I can see where it dips, and what coin we were at then.

I can probably help you with some profitability graphs. Let me see what I can do with some of the data I already have, although not ideal for that purpose. I have already disposed of much of my detailed data over the past few days that I was analyzing. I was doing the "painstaking manual lookups" you refer to, puzzled by what I was observing.

As a point of reference, I'm running 4 7950's so nothing old or unusual.  When you convert to those "easy" coins, many many minutes go by without my being able to submit a single share due to "new block" messages.  Hard to make anything while that is going on. All I can think while I watch it go on is that you must not be seeing what I'm seeing...

[cryptopi]

...
Then I can see where it dips, and what coin we were at then.

The pool is mining one of the losing coins right now. In the last 4 minutes that I have been watching, my 7950's could only squeak in 1 share between the zillions of new block messages.  No way that will be profitable...  Oops, just squeaked in another one while I was typing...

[h2odysee]

The pool is mining one of the losing coins right now. In the last 4 minutes that I have been watching, my 7950's could only squeak in 1 share between the zillions of new block messages.  No way that will be profitable...  Oops, just squeaked in another one while I was typing...

Yeah, we have a 25% reject rate. But the math says we're 3 times more profitable than LTC. It will be nice to know for sure though.

[ocmoho]

The pool is mining one of the losing coins right now. In the last 4 minutes that I have been watching, my 7950's could only squeak in 1 share between the zillions of new block messages.  No way that will be profitable...  Oops, just squeaked in another one while I was typing...

Yeah, we have a 25% reject rate. But the math says we're 3 times more profitable than LTC. It will be nice to know for sure though.

is it not worth it even for 1 day to try 256 diff?

[btcdrak]

The pool is mining one of the losing coins right now. In the last 4 minutes that I have been watching, my 7950's could only squeak in 1 share between the zillions of new block messages.  No way that will be profitable...  Oops, just squeaked in another one while I was typing...

Yeah, we have a 25% reject rate. But the math says we're 3 times more profitable than LTC. It will be nice to know for sure though.

is it not worth it even for 1 day to try 256 diff?

Yeah, common... diff adjust has been requested way too much and been ignored. Half it and see if we get better results. For now I've had to switch back to mining myself because the pool is way too unpredictable atm.

[cryptopi]

The pool is mining one of the losing coins right now. In the last 4 minutes that I have been watching, my 7950's could only squeak in 1 share between the zillions of new block messages.  No way that will be profitable...  Oops, just squeaked in another one while I was typing...

Yeah, we have a 25% reject rate. But the math says we're 3 times more profitable than LTC. It will be nice to know for sure though.

You are correct in this case.  I should have checked the actual numbers before I made the claim I made based solely upon what was visible in the miner window. My bad.

Over the last 90 minutes, profitability is high, I am running at 0.07BTC per day per Mhash. Highest I have seen in 24 hours, and in fact triple the recent average.

Regarding past poor periods, try looking at:

Very low (essentially zero) from 2013-08-05 03:49:12 UTC to 2013-08-05 04:39:08 UTC
Very low (essentially zero) from 2013-08-05 04:59:07 UTC to 2013-08-05 05:25:15 UTC
Very low (essentially zero) from 2013-08-05 23:57:58 UTC to 2013-08-06 00:20:49 UTC

Since 2013-08-05 04:39:08 UTC, the run rate I have experienced has been running at .023BTC per day per Mhash.

[Prelude]

I have to agree. Let's try 256 for a day or two. If that costs you more in server bandwidth, feel free to bump up the fee a little during the testing period.

[btcdrak]

I have to agree. Let's try 256 for a day or two. If that costs you more in server bandwidth, feel free to bump up the fee a little during the testing period.

It most certainly wont cost extra bandwidth and server allowances are so large these days it makes no practical difference. It's just if his server can take the incoming requests. It would be pretty easy to test - just drop the diff and watch the server load. It's not like he's risking anything and there is everything to gain. I assume of course he's using his own server and not a small VPS.