....
What do you think ?
When all the other 4 pools have no issue, and when zergpool has this issue for 6 hours making 4500 miners loose all for 6 hours, it's something from bad management of the pool, right ?
Also AM should implement a protection against this type of behavior from pools, right ?
Once I get the current development release done and released as v4.7 I will start investigating how Awesome Miner can be improved to detect more of these pool related issues.
I agree that Awesome Miner should be able to analyze and find pools that are reporting unrealistic numbers in terms of profitability. Please keep in mind that when you mine on Zergpool and similar, Awesome Miner may not have full insight in the coin details of what you are actually mining. The profit information is however always known.
@eminer, I think you could take a break from mining at a pool, at times like this, ppl are rather sensitive cause you are no longer making 15 dollars a day with 1080Tis, and it's going to continue to be the case unless BTC picks up the steam again (If and only IF). That being said, you know why other 4 pools are fine? (I'd correct you that the online services, there are only 3 "other" pools, and out of the 3, HashRefinery don't currently have x17 listed. that leaves you with the 2 and they all shut the xvg pools down following ocminer's suit @ SuprNova, Zerg also followed suit, just not as fast...and you probably haven't realized that pinpins is also human, he needs sleep.
The other factor is that you got to be joking if you think Hackers are going to inform everyone as to WHEN they will carry out attacks? 6 hours response time is reasonable, nobody gained, the pool itself is also a victim.
@Patrike
Some ideas, I'm sure many other's would also love to share their experience and opinions on how to tackle this. I've been mining obscure coins on various pools and uses @soothaa's coin plugin + my own implementation based on his work. What is obvious IMHO is that difficulty plays the greatest factor in the fluctuations. It is certainly more pronounced with new, obscure, new unpopular coins since the difficulty Delta% can be rather high.
Another obvious thing is that relying data on WTM only is also causing an issue, the siteOP simply cannot actively keeps track of all blockchains state and there's been already several coins having stats stuck for hours in the past few days, some are even Active(not listed) and not flagged as lagging LUX has been stuck at 5184.281 difficulty for the past 8~10 hours at WTM today....still stuck now.
Thus, I believe, some sort of cross check between WTM, or the ability to read various explorer's (including pool's) difficulty value would be a good way to provide a reference safeguarding figure as well as redundancy. For personal use currently, I already am tapping into actual pool's reported difficulty for several coins even if they have json @ WTM...that to me, makes a difference (WTM being rather unreliable lately or just me ;p)
From there, you have a very current difficulty value, this could simply used to compare with the 24h value readily available from the pools or WTM, and set some formula to detect that if the current difficulty value if stayed at it's level for a defined period, would drastically cause the 24h Difficulty %Delta to skew such that profit becames unrealistic. Where to find the best values so it balances is subject to tweaking, either hardcoded, or can be defined by user just like the profit switching % threshold.
my 2c... just to get the brain storming going so some long term solutions can be developed and implemented.