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.Is there any kind of workaround? Haven't had a closer look at cgminer api but perhaps the bitminter api works better?
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?
just kidding. I would be interested too. Maybe their bitcoind had just restarted and there was no transaction to include in the block at that very moment? 
