Thanks for your reply. I recognized that calulations are correct. But 'supervising' a bunch of small miners by the provided live stats (my account -> workers seems) not really praticable.
Is there any kind of workaround? Haven't had a closer look at cgminer api but perhaps the bitminter api works better?
The pool API is based on the shares you submit, since that is all the pool knows, so it's accuracy over a short period of time is quite unreliable - finding shares is statistically random.
My cgminer API, on the other hand, reports the counted hashes done by the devices
(or with ICA and MMQ, it counts successful hashes and reasonably accurately estimates valid aborted hashes if configured correctly)
Thanks for your input, kano. Even my very, very slow 30Mhps-test-miner is running 24x7. Therefore calculations could be made on a reliable basis, I think. But even after some days figures on the live-stats page don't seem to become more realistic.
(I hope I don't start any shitstorm with this:) Mining with this tiny "rig" on other pools showed always nearly accurate figures there.
So I don't think submitting shares (and therefore providing enough data for exact speed calcs) is the point. At least to me (n00b) it seem's like it's more a question about the background processes running on DrHaribos servers.
With deforse mining at around 300Mbps and having the same issues it's seems not an good idea to change to this pool as I have about 8 miners with 120-180Mbps and need to see if all of them are doing their job, right?
No, I was comparing a pool API to a miner API (in this case I was referring to the cgminer API)
If you are talking about the DrHaribo miner API, then it should be accurate also.
The problem (again) with any pool API is it only knows about shares.
You get one (1diff) of them on average every ~4 billion hashes.
The miner can usually count single hashes so of course it will be way more accurate and over a much shorter period of time.