Topic: [ANN] profit switching auto-exchanging pool - www.middlecoin.com - page 494. (Read 829908 times)

would it make sense to split the pool in 2 or 3 ports?

so u could direct one port to such coins?


what if the pool grows and u have 1, 2 or 3 ghash?

This pool does not pay out everything you earned in a given 24 hour period. If you were to stop your miners cold, you're still going to get paid the next day, or even 2. As I understand it, there's a buffer that builds up due to the time it takes for blocks to mature, to transfer funds to exchanges, do the exchange itself, and transfer them back out.

In order to understand what you're making in a day, switch one of your rigs to a separate address, and run it for a specific amount of time (the longer the better), and then disable that address. That way, you have real numbers with a known amount of time, and you can calculate how much you're making per unit time.

Shame we aren't mining global coin at this present time...

Globalcoin   scrypt   60408   0.023   100   0.00000432   Cryptsy   2,806.08%   2,477.72%

Quite the profit margin.

Shame we aren't mining global coin at this present time...

Globalcoin   scrypt   60408   0.023   100   0.00000432   Cryptsy   2,806.08%   2,477.72%

Quite the profit margin.

the .15 payouts(would be making ~.24 JUST ltc'ing

I haven't had a payment yet, hashed for over a day at 330kh

I've got some explanation and 3 graphs. First one is an overview of a 2 day time period. Can see general trends, but not details. Then two sub-graphs that show the details of two periods in the general graph when I collected a bunch of details for you.

I didn't know if you wanted stuff like this in the forum so I figured I'd send it this way. Figured I'd leave you in control of the detailed information flow.

First, some explanation about the data / graphs:

I mine with 7950s and graphed the results on the charts. All times are US eastern standard time zone (EST).

Graphs display the daily effect of the change in levels of BTC in all forms (sum of immature unexchanged, unexchanged, and available balance). This is the only way I can see to compute productivity since you only post results every 3 or 4 minutes and balances shift between categories during that period.

The graphs show both the instantaneous and smoothed (rolling average) mining results. As such, they contain not only the results of mining, but fluctuations in the value of unexchanged coins and the loss of any “failed” immature coins. At times, it appears that the fluctuations of the net balance (reported as productivity has a large component related to value fluctuations (immature and BTC balance remain constant, yet unexchanged balance changes in value). Data like this is choppy, but it should give you a good idea of what is going on. Just don't forget to take into account the lag effect when mining things with immature problems or rapidly changing exchanging rates.

Any flat sections of the graph lasting more than 5 minutes are averages during the time period that I did not collect frequent data (is a manual process). Although accurate, they can only be used for aggregate results and should not be used for detailed productivity determination. The change in height from one of these longer flat areas to another does not reflect when the change in productivity occurred, but is merely the cum average since the last data point at the time when I took the new data point. When data is being actively collected, the graph will show a change every 3 or 4 minutes, and do so consistently, as shown most of the time in the detail graphs. 

Now the graphs:









Please advise if I can be of other assistance. Your pool is great; we just need to get rid of the coins that prove to be less productive than a paper calculation would indicate. There is probably some interplay between my miner settings and the results, but mine are fairly generic so likely representative of most folks that are trying your pool that you would like to retain.

I maintain data like this on an ongoing basis, although not usually as detailed as the two inset sections I included above (takes a bit of time, did because I though it would be of use to you). Usually I grab a snapshot every few hours, sometimes every 30 min or less. If we could ever coordinate when you are switching to coins that you want to know about, I can specifically try to get data at that time with higher frequency.

Again, let me know what I can do to be of assistance to you. Happy to clarify anything about the graphs if they are not clear. Also, can send detailed / blown up graphs in a word document or whatever if you would provide an email address to send them to.

Keep up the good work, I'm sure it is not easy. If I can ever help you with any data analysis, just let me know. Your database should contain a wealth of information useful in optimizing the results of the pool (and thus your results).

You can give it a try. But with your hash rate, it is not worth it because of the 512 difficulty level. Please report back the trial results.

Is this also useful for people with low hashrates? I'm going to give it a try on my 340 Kh/s.

Pool is indeed back up after a couple hours of downtime.

are you sure only 0.035 ? i think mining just ltc is better if that is the case?

Did u change these values in cgminer.conf?

queue 0
scantime 5
expiry 5

You will get a ton of rejects if you don't as the pool mines alot of coins with fast block times. I dont see any difference mining coins with higher block times with those settings.

Today's profits were 0.0350 BTC per MH/s per day.

Actually, it's slightly less than that, due to something I don't understand yet. The total hashrate drops, whenever our reject rate increases.

You can see it in this graph: http://middlecoin.com/hashratecharttest.html

The hashrate dips when we switch to a high block rate coin.

Here's a scatter plot, showing the relationship of the rejected percentage to the hashrate: http://middlecoin.com/rejectvshashrate.html

I'll be adding this new information into the profit calculation.

My best guess as to why this is happening is that miners are using --no-submit-stale, and the lost hashrate is all stales. But I really doubt stales would account for that much loss. So I really don't know why.