I am not sure I correctly understand what you are writing. But if I do: there is no way to predict when exactly a given block will be found by the pool. Looking at the characteristics of the CDF (https://mining.bitcoin.cz/stats/graphs/) you should ask yourself, after how many minutes in the round exactly a 'strategic miner' should join to realize any advantage.

Before starting your own assessment on the topic, it is worth to read what others have already shared regarding this reward calculation method:
http://organofcorti.blogspot.com/2012/08/42-slushs-score-method-and-miner.html
http://organofcorti.blogspot.com/2012/09/43-slushs-score-method-and-miner.html

Hope this helps,
   T

I do not think it is very difficult. The value of each share you submit is calculated with the following formula:

score_share = exp(t/C)

where t is round duration in seconds, and C is a constant, currently 200. This means the value of each share is exponentially growing, so old share have significantly lower value compared to recent shares. So if you stop mining while others don't, your part of total pool score for that round will decrease exponentially. You can read the original post about this reward calculation method here: https://bitcointalk.org/index.php?topic=1976.msg50002#msg50002.

Additionally, based on measurement I have found that each hour, t is reset to zero and your score is divided by exp(3600/C). This is probably to prevent an arithmetic overflow (see http://en.wikipedia.org/wiki/Arithmetic_overflow).

Hope this helps,
   T

This day is full of unusual events. Status of last 3 rounds is still "processing". Usually this state lasts only for about 10 minutes.

19260    2013-07-23 22:02:41    0:43:37    Processing...    248132    25.01926064    99 confirmations left
19259    2013-07-23 21:19:04    0:37:33    Processing...    248129    25.47314137    96 confirmations left
19258    2013-07-23 20:41:31    5:04:01    Processing...    248128    25.17930000    95 confirmations left

Mining seems to be running fine, the reward calculation seems to be paused - maybe some upgrade/change in the pool infrastructure is processed?

Yes, I have also confirmed it via blockexplorer during the outage of blockchain.info.
Everything is back to normal by now on the stats page as well.

   T

Weird indeed. Wanted to look up but blockchain.info is down.
Does anyone have info about what was happening?

   T

The reward you get for one single share depend on when the share was submitted. The score you get for the share is exp(t/C) where t is the number of seconds since the round was started or since the last reset, and C is a constant (200 based on my measurement).
The time a given miner (w/ constant hashrate) spends working a single share varies. Even is the difficulty is the same.
If you were lucky to submit 2 shares in the last few seconds of the round, you will get much more for the round.
If you were unlucky and were working on a share and the round completed before you submitted it, you will get a smaller reward.

Hope this helps.
   T

No worries, magic happening right now - it looks like it will be fixed in a minute.

   T

+1

magic happening right now

Yes, the same here. Be patient, similar cases in the past have been fixed by Slush.
Start worrying (and raising attention) when the number of confirmations left gets below say 30.

Cheers,
   T

I will send you a PM. I tried to look for how exactly the rescaling works, but have not found detailed docs. I would really appreciate a link in case you have it handy.
Regarding reverse engineering the current value of C, I have read your blog post on the topic (http://organofcorti.blogspot.hu/2012/09/43-slushs-score-method-and-miner.html), kudos to you, I enjoyed the read.

My idea was changing C on each rescaling, then resetting it to the original value when a new round starts. This would indeed affect the hop point. Honestly, I have not dived deeply into the hopping aspect of changing C intra-round yet, my first point of interest was checking how variance is correlated with the time elapsed since the last renormalisation with and without changing C.

I would avoid going public prematurely, the community might be a bit harsh and I do not want to raise a flame war before I can properly back the points. I'll PM you, you are way more experienced with this type of statistical analysis than me so any idea/comment is welcome.

Cheers,
   T

Thanks for the response, you are absolutely right. I do pull the statistics via the JSON API every 10 minutes and analyse & plot it automatically every 6 hours. (I do not want to pull more frequently for practical reasons.)

At this point in time, based on stats from the last 2 months, what I see confirmed is the "magical fix" manual recalculation via PPS which is easy to spot and slush has been honest about it when I contacted him (he is very open and honest, and I do understand him not wanting to actively post here recently).

I do not think that based on my current amount of data I could back my assertion beyond a doubt, this is why I was very explicitly calling it a guess. I could collect data and perform "black box analysis" for any amount of time and still not reach 100% as it is theoretically impossible to reach 100% via passive black box analysis but the confidence level is growing with the amount of data collected.

Checking the code (aka white box analysis) could be much less effort taking and allow for a statement beyond doubt. And honestly, I have never even seen a precise description of what exactly is done on a renormalisation, only the fact is mentioned that a renormalisation is periodically performed. In contrast to this, Meni Rosenfeld is very explicit in how rescaling should work when using DGM (https://bitcointalk.org/index.php?topic=39497.0).

Regarding changes to C: what I mean is that on rescaling/renormalization, when the score is changed, but C is not, then you very aggressively change the weight of all the work one has performed before renormalisation versus the weight of the new per share increment. However, if the score is divided by X, and C multiplied by log(X), then the value of previous scores relative to the value of the increment score for the new share is kept the same (maintaining the exponential semantics used by slush), and you will end up with the same exponential curve, just rescaled (zoomed out).

Cheers,
   T

OrganOfCorti,

I have read many of your writings and comments here and I am convinced you do know very well what you are talking about. However, with all respect I am not sure you are 100% right in this case. Yes, what you write is how it should work, but I wonder if you have seen and analysed the actual code performing the renormalization. What we know from experience is, that a round, that ended very closely after a renormalisation, yields rewards being off by magnitudes, which affects some miners in a positive, others in a negative way. It seems, the closer to a renormalisation the round ends, the larger the deviation from the expected avg reward.

My guess (which is only a guess based on observations) is that constant C in the formula is not changed after the renormalisation to match the scale-down factor of existing scores. If it was correctly changed, then a share submitted right after a renormalization would have the same impact/importance, than the share submitted right before the renormalization. This does not seem to be the case.

In really extreme cases, where the deviation is significant (e.g. only a few satoshis for continuous miners even at around 1Gh/s), Slush recalculates the blocks manually with PPS. You can see that after a "magical fix" that we see in some cases your score is equal to the number of shares you submitted. (I have been collecting and storing block stats for two months and am not just making this up.)

Please let me know if you think I made a logical mistake in my conclusions, I am always open to learn. And it also belongs to learning to periodically revisit and challenge previous theories and statements. So no offence is intended whatsoever.

Cheers,
   T

Slush,

block 18309 has 10 confirmations left an no action taken so far. While this is not catastrophical at all, it is unclear if the notification made it's way to you or not.
Please let us know your preferred way how such issues should be escalated to you in the future. Shall we:

 * post to this topic once and wait patiently for the block to get fixed
 * post multiple times / make more noise (I do not think this is ok)
 * send a PM on this forum
 * send a mail
 * something else (please specify)

Note that I am not complaining, but just looking for a way to ensure proper communication regarding similar issues in the future.

Cheers,
   T

So am I...

It would be useful to be able to make info about reoccurring issues sticky / always on top. Currently, there is a massive volume of post only marginally related to pool issues, which makes finding info you are looking for rather demanding.

Yes, this has been covered a couple of times. Score resets are performed periodically so no arithmetic overflow happens.
There were some comments around re-normalization versus reset, the first one being more correct while the second one easier to implement and quicker to perform.
Another approach to eliminate an arithmetic overflow is using a logarithmic scale, but that would also need changes to how rewards are currently calculated.

Check here for a detailed description of how the scoring used at this pool works (the reset/re-normalization is also mentioned): http://organofcorti.blogspot.hu/2012/04/41-slushs-pool.html

Some time ago there were indications Slush is planning to switch to DGM. See here: https://bitcointalk.org/index.php?topic=39497.0 - the post also describes recommendations around eliminating the possibility of arithmetic overflows, in one prefers to read up on the topic.

Hope this helps,
   T

Ok, so you get the boost with crossfire cable, but crossfire disabled in the OS. Thank for clarifying this.

Take a look at this: https://en.bitcoin.it/wiki/Mining_hardware_comparison#AMD_.28ATI.29

There you can find os/driver/miner combinations along with worksize, vector, threads, clock and memclock settings and measured hashrate.
If you are optimizing for sha and not scrypt, then you can downclock the memory to decrease thermal dissipation which in fact will allow you to get better GPU performance.

Hope this helps,
   T

First, let us know what you get with only 1 card in your MoBo using the very same clock & other parameters. Crossfire is known to decrease mining performance, this is pretty much in contrast with what you experience. Obviously you will not get more with 2 GPUs than 2 times the performance of a single GPU - but let us check how close you are to this.

With those clock rates and 2 6870s you could easily go above 650MH/s this is why I suggest to test what you get with 1 GPU only.

I assume you are running windows - on Linux, multiple GPUs seem to work well without a crossfire cable and without dummy plugs, the hashrate is the sum of the rates of the individual cards in my case, even for heterogeneous config (mixed version GPUs).

Cheers,
   T

Just for your info, this is merely a windows issue - a dummy plug is not necessary when you run Linux. Multiple GPUs hashing fine without anything connected.

Hope this helps,
   T

I store stats of blocks found by the pool since the DDoS mid April, and also plot various charts via gnuplot every 6 hours - all automated via cron & a couple of scripts.
I also include the difficulty increase so I can correlate it with the trends in my cumulative reward. But I do not think it would be a bright idea to paste all the data right here

Using http://pastebin.com/ or similar services for bulk data could help a lot in keeping posts short and to the point.

Cheers,
   T