Round 21027 has the same 1% of the expected payout that most other people here are seeing for me as well. I don't believe that it is a connection issue on my end, as my number of shares / total shares is the same as every other round.

So I just added 10gh/s to my total setup, everything is reporting full hash on Slush's site but my estimated reward doesn't look bumped up much at all. Does this mean everyone else plugged in 10gh/s at the same time as me? Or did we get more members so proportionately I'm nearly unchanged? Or does the estimated reward need more time to catch up? Perhaps I was expecting to see more of a bump, I mean it's a little bit higher but not much.

So I just added 10gh/s to my total setup, everything is reporting full hash on Slush's site but my estimated reward doesn't look bumped up much at all. Does this mean everyone else plugged in 10gh/s at the same time as me? Or did we get more members so proportionately I'm nearly unchanged? Or does the estimated reward need more time to catch up? Perhaps I was expecting to see more of a bump, I mean it's a little bit higher but not much.

The pool hash rate is changing all the time, but say it was 400TH/s when you plugged in (it's 422TH/s as I write this), and where in the round you connected affects the reward as well, but in terms of hashing power 10GH/s divided by 420TH/s times 100% = a relative increase of 0.0025% for the pool, so yeah, the reward bump wouldn't be a lot.

So I just added 10gh/s to my total setup, everything is reporting full hash on Slush's site but my estimated reward doesn't look bumped up much at all. Does this mean everyone else plugged in 10gh/s at the same time as me? Or did we get more members so proportionately I'm nearly unchanged? Or does the estimated reward need more time to catch up? Perhaps I was expecting to see more of a bump, I mean it's a little bit higher but not much.

The pool hash rate is changing all the time, but say it was 400TH/s when you plugged in (it's 422TH/s as I write this), and where in the round you connected affects the reward as well, but in terms of hashing power 10GH/s divided by 420TH/s times 100% = a relative increase of 0.0025% for the pool, so yeah, the reward bump wouldn't be a lot.

Do a lot of people turn off over the weekends? I always feel like the weekends have longer rounds during certain hours but slightly better rewards. I'm not plotting any data, mostly this is just very casual observation... I'm 24/7 with my equipment so I just assume most people are the same way.

I've also limited myself to just Slush's pool, it works well enough so I've had no motivation to bounce around or explore. Perhaps during the long blocks people drop out and come back a few days later. I'm pulling at straws, guess I'm just trying to find out what might make the pool hash rate decrease, assuming it ever does I'm aware it would only be temporary and the long-term trend is always building here...

Edit: just so I understand, generally if my rewards get lower and it's not from a difficulty jump is it safe to assume it is because the pool either has more members or more equipment plugged in?

Edit 2: okay, now my estimated reward is higher by the amount I was expecting, perhaps there was some lag in the system(?)

Round 21027 has the same 1% of the expected payout that most other people here are seeing for me as well. I don't believe that it is a connection issue on my end, as my number of shares / total shares is the same as every other round.

Hopefully Slush fixes it, he's usually excellent about such things.

Usually he has been. But normally the correction should come before the block is verified. After verification, payouts could have occured, especially to those who had won unproportional gain in the round.

(...) but I think that "anti-pool" hopping routine is overly punishing Shares that come to the server just a few seconds late.

Rejecting shares that have come late for the work just finished (a block found either by us or by somebody else) has nothing to do with anti-hoping algorithm.

Quote

I mean when a round is i.e. 10 hours and I contributed @ full average speed for 9h 59m with the final shares somehow being a tad delayed (despite my GUIminers showing no evidence of any delay/problem whatsoever), that shouldn't be punished so hard.

So are your shares delayed or not? :-) Somehow... :-)))BTW, do not use guiminer...

Quote

Just stopping miners (which ran days uninterrupted 24/7) for only 10 seconds (!) to change some settings is making the rewarded BTC taking a considerable and unproportional hit, IMHO that's not okay and making me considering to at least try other pools.In the end results, their additional fees become insignificant when compared to the losses I see here everyday due to that extremely aggressive scoring/time vs. reward reduction routine :/

Do you think that you manage to always break your mining just before the round end for maintenace?BTW, a 10 seconds may make some hit, but not a considerable one. The anti-hoping algorithm parametres had been even relaxed a bit lately AFAIK.In most cases, when you break your mining for 10 seconds, it occures somewhere during the round. And the resulting hit will be negligible.Tuning the settings is a rare occasion in normal operation. Pool fees OTOH are a regular all time cost.

Quote

Additionally because of being new around here, such events always leave a nagging doubt that this behaviour is systemic and intentionally scooping off small fractions of BTC Rewards per participant. No proof for that of course but the doubt remains (especially because now big money is involved every day), those repeating small issues don't quite reduce these doubts :/

Just my 2 cents from a low profile miner, I'd probably be much more unhappy if I had some big THash rigs rolling and seeing the same...

Just look into your own mouth. If something like that was going here, large miners would notice long time before you could. And if you are either unsatisfied with the scoring algorithm, or in doubt about the pool consistency, you really can consider joining another pool.

The usual reason for low payouts is down to the internet deciding to run slow.

My normal connection speed is approx 8meg

I can be watching an online film and the video is reporting 4.1meg. My miners are also working normally.

The video feed will suddenly freeze and report speeds of 0.1meg(slower than old dial up). If the freeze lasts more than a few mins and a block is found during the freeze time, then the payout for that block is low. My miners are still running apparently normally.

If I were to monitor the miner carefully at this time (very difficult with 80+ devices) I would probably see an increase in Reject and Stale results, but within a few mins this would be lost again in the background.

Slush is paying more for the freshest calculations and much less for the older results. So if the hashes are not getting to the pool before the block is found, then they will not count towards the payout. (The pool thinks you are skipping).Late arrivals are not counted.

I agree but I also think there is a chance "late arrivals" may very well count towards the next block. I will see a low payout and the next block sometimes will make up for it as I thought the late shares get credited towards it?

Quote from Slush's Pool:-

How does bitcoin pool work?

Our server gives users blocks of very low difficulty to solve. Each solution found is registered as one 'share'. Occasionally, a solution will happen to also meet the full-strength difficulty requirements of the Bitcoin network, resulting in a successful 25 BTC minting.

This 25 BTC is divided among all of the users that contributed to that round, weighted by the number of shares that they earned. Therefore, the reward earned by a given user is given by the following formula:

(25 BTC + block fees - 2% fee) * (shares found by user's workers) / (total shares in current round)Shares do not carry over from one round to the next. When the pool mine a block, only users who worked on that block are rewarded, and only for work they did on that block. This is an unavoidable consequence of the way that Bitcoin mining in general works.

Late arrivals go in the bin

Thanks for posting... I was just going off what I see on my rewards. More times than not it just seems when I see a really low payout I will see a higher than normal one on the next block. So it must just be over observation on my part.

I just created a very simple script (php/mysql) to track my personal progress on the pool, fetching the data every 30 minutes. I want to use this for some detailed after the fact ROI analysis.However, I noticed that not all fields that are visible on the stats page are provided in the JSON response from the API. Would it be possible to add these?

The fields I am interested in are the following (I am using the personalized API with an API token).

For blocks:

My Shares

Block value, including TX fees

The slush block number, although not really relevant I would like to add it just for reference purposes

For the pool itself:

The current difficulty

That would really help!

If anyone is interested in the script: currently it does absolutely nothing but fetch the data at a regular interval (cronjob), and it is by far the ugliest piece of code I have ever written (in 30 minutes) , but it does the job.I'd be more than happy to share it with you if you want, but don't expect anything fancy just yet!

I just created a very simple script (php/mysql) to track my personal progress on the pool, fetching the data every 30 minutes.

Another member - Sunriselad - beat you to it and created a utility to do most of this. It's called Mine Minder, and includes the block values, pool hash rate, and current difficulty. It also displays a current bitcoin value, but I do not know what the source is. It does not include the Slush round number. Apparently there is some difficulty in getting the individual shares per round into the feed.

I have my copy set to download every 300 seconds (5 minutes); I believe the default is much lower, which would seem to impose an unnecessary burden on the servers.

You should be able to find the relevant post on the forum.

[Edit] try post #8211 on page 411. Discussion follows, and there is a later version than the one mentioned.