Underpayments on the long blocks will be made up retroactively regardless of whether a miner has continued on the pool or not.

You're describing pool hopping in a roundabout way. Preventing it from earning more is the whole point.

This does explain your confusion a bit. At no time are either "value" or "earnings" reset. They both continue to accumulate. If you miss a round, you just pick up where you left off whenever you want.

Wow, nyargh is stupid and snarky.  Hilarious combination.

Protip: The only way to get and keep 100% of your earnings is to solo mine.  People that mine in pools accept a certain tradeoff.  Luke-Jr's implementation is better than most, on average, if you actually did do the math.

I like people that pick only a few words of information and preach it ad nausea while declaring themselves the most clever.  They're fun.

The basic idea is to add a "value" balance counter that goes up by a fixed amount with each share your miner submits. This balance goes up by 50 / difficulty for each accepted share your miner submits to the server.
This "value" balance is then used as an upper limit for payments.

Perhaps my mistake was using English words for technical details...

I missed your point... what was the problem with this?

Does this mean that the only way to fully drain 100% of your mining earnings from the pool is if the pool encounters a string of long blocks, forcing the pool to pay out your 'banked' earnings?

Personal best on this 5830 is stable at
320 Mhash/s
still 2.1 SDK
phoenix+poclbm
1025/320
90%

Still need to play with phatk, overvolt, flexible proxy miner, etc.  Fun little toy project   Card will in theory try to go up to 1200 GPU core, so I'd imagine I might in theory be able to get up to what... 350?  I don't think I can do that with stock cooler and volts though.

I cannot reproduce this bug.

Are you sure you're using the absolute newest version of my miner? mtrlt's 0.5% speed increase accidentally had a bug that would cause similar behavior to half of shares missing. I fixed it shortly afterwards.

A dead giveaway of the bug is using -dd and seeing a ton of hardware check errors.

it's a single 6870 from sapphire, using sdk 2.4, ubuntu 11.04 (I like unity, even though it might put some load on my gpu) and apt says my driver is "fglrx 2:8.840-0ubuntu4".
No manual over/underclocking.

* sometimes not submit/recognize a share even if it is valid.

Thanks!

Using: -k phatk DEVICE=0 VECTORS BFI_INT FASTLOOP=false WORKSIZE=256 AGGRESSION=13 on a single 5830 and get 312MH/sec
 

Now my shares don't seem to be showing up at all? 

16xwypiCcnwJCFyFThhomXWy6A9uWWn4L4 is me


Back to slush...

Nope, my hashrate is 100% correct. The problem is, OTHER miners do NOT look for OpenCL execution errors and happily count the hashes on a failed run.

If your Intenret is lagging badly, all miners, not just mine, will have strange hashrate drops because its blocking on share submission.

If you think there is actually a problem, compare vs a local running bitcoind.... if it STILL has large variations in hashrate, then there is an issue.

In addition to that, less than -f 15 often causes the OS clock to get jerky up to the point that the 15 second average (the first number) becomes very unreliable. In these situations, use the forever average only (the second number)... it usually becomes reliable within a minute or two.

Other miners suffer from this, but try various ways of covering it up; none are as accurate as using the forever average on mine over long periods.

After testing various parameters, I found a way to get 2mhash/s more out of diablo compared to phatk. Great!

However, for the last 5 hours, deepbit never calculated a hashrate for me that was even close to the 270mhash/s shown by diablo. It was mostly ~150mhash/s, sometimes as "high" as 200mhash/s. (Using a 45 min average) (also, 1.65% stale shares - might be caused by deepbit though, not sure if long polling works 100% again)

Is it possible that certain parameters cause diablo to display a much higher hashrate than actually achieved (for example because some of the calculations fail silently), or is this just very bad luck?

sorry to keep bringing up the same topic again, I just want to make sure I understand what's going on.

it's now exactly 72 hours of nonstop 240mh/s going to the eu-eligius pool. hashrate shows up in the pool statistics just fine, with the expected variations but pretty close on average.

now my total earnings for these 3 days are 0.8 BTC, whereas the calculator estimates 1.68 for this time.

Is this just bad luck with the pool? would switching to a larger pool (us eligius or one of the other bigger ones) help me getting (much) closer to the estimated rewards? less than half is kinda depressing

I've had 220 or so going to eligius for a few days. 2 hr average hashrate hovers pretty close to 220, with dips and spikes of varying degrees.