Quote from: Terk on July 06, 2014, 03:07:11 PM

Quote from: coinflow on July 04, 2014, 03:42:52 PM

Quote from: Terk on July 03, 2014, 09:29:09 PM

Quote from: coinflow on June 29, 2014, 01:36:08 PM

I'd also say, that this is the main problem.

It works like this:
The miner is working on a coin, while the pool already switched to another coin. The miner submits the done work to the pool and the pool answers: "Don't give me these results, they are no longer valid, because we are already working on another coin", throws it into the bin, and the submitted work is not counted for your REAL hashrate (the "pool-hashrate"). That explains the difference between what the mining-software shows and what the clevermining-website displays.

This isn't the case at CleverMining. When we switch to a new coin, all old work for previously mined coins is still valid and will be accepted (until there is a new block at these other coins which will obviously invalidate the work). This is the reason why you should never use --no-submit-stales at coin-switch pool. We do things the smart way and always accept work for previously mined coins. (if we didn't, rejected percentage would be an order of magnitude higher).

OK, if it works like you describe, why are there massive break-ins in the hashrate from time to time, which causes a really severe lowering of the overall hashrate?
On other pools, that don't switch, it doesn't occur. If all submitted work counts, a drop in hashrate should not even be the case, when the pool switches to the next coin.

Because some users are switching between coin-switch pools if temporary pool results/luck is lower than usual, while people mining at a single-coin pools don't do this. Some people don't understand that even coin-switch pools have their variance and good/bad luck and it's best to pick the best pool based on long-term results (or other features/qualities you like) and stick to it.

(because if the pool has good results in the long term, then a worse than average period will be followed by better than average period and you will be fine in the long term if you stay. If you switched away after worse than average period you will miss the better than average period and your total results won't be as good as if you didn't switch away)

I think, you did not understand what I meant. I wasn't referring to the overall hashrate of the whole clevermining-pool including all users, but the single hashrate of one user.
Why is it dropping, if you count each and every submitted share even of the previous mined coins, after the pool switched? If it was like this, the hashrate could not drop from let's say 80 MH/sec to 60 MH/sec. for some time (sometimes 5 minutes or more), right?