just got back home and checked what the morning CPU mining did... total of 7 shares found, dificulty 1 ( max of 1.1MHash/sec when firefox is closed etc ) and find the following block is calculated ( and time showing last 2 of them were at end of round )
17791 2013-05-01 20:01:25 5:00:24 36782329 7 0.00000000 234096 25.58139100
normaly i'd shrug it off due to the over 36 million shares, this time i know at least 2 shares were in the last few min of the round
Unfortunally for such long round you probably need last minute not last minutes at that speed...
i'd believe most of the advice and as I have previously stated ( somewhere in this thread ) getting 0E-8 is my ' usual ' for CPU mining.
That said, in another round i get the following.
17795 2013-05-01 23:34:54 0:26:48 3199350 1 0.00000002 234122 25.10240000
For the duration/shares versus timing of the share, it seems that there is something wrong with the system since DDos attacks.
I am not crying ' boo hoo, 7 shares and got squat ', to the contrary, i'm saying i KNOW i got 2 in the last 10 min of a round and got squat and not like the newly mentioned payout for only 1 share on a short round. I also recommend for those that can LOG when/how many shares to do so and start looking at the timing of the depreciation of shares per round as I suspect that is the issue.
If I find more like this, I will not be posting it here, i'll be sending the info to Slush. I ask you do the same.
This all could still be fallout from the attack and I do not mind the 10% Slush gets when I use GETWORK. I do however mind if there is something wrong and no one looks in to it to see if they also are experiencing the issue so it can be looked at properly. I never did say how many PCs i got CPU mining, just that I do CPU mining currently.
It's a bit tricky to guess what's going on here. I have no doubt you're seeing what you describe, but the only thing that can change your payment is a change in the score method, so it's probably not an error at the pool end.
Here's some ideas off the top of my head:
* Slush's score method causes more variance for miners. CPU mining has a very low hashrate, with few shares submitted. Someone with a higher hashrate would see increases and decreases in their earnings, but if you are only submitting a few shares per round you'll see rounds where you have no reward at all, and others where you have more reward than expected (your expected reward per share is B/D, or bitcoin reward/difficulty).
* As the pool hashrate increases its proportion of the network, your score decays faster since more shares are being scored in the same time period.
* Slush might have changed the 'c' in the score method. As the pool increases its share of the network, 'c' must be increased to keep the pool less hoppable. Increasing 'c' increases the variance, so it wouldn't be surprising (in your case, at your hashrate) to get a bunch of 'no rewards" in a row.
None of these might be right, but it does give you an idea of the complexities involved.