Page 2 of 2
Re: Status as of Monday, July 31, 2017
Posted: Mon Jul 31, 2017 7:45 pm
by wkying79
FRISKIE wrote:
A superb post!
In case Steve is not in favor of a permanent delay in the profit data feed, perhaps we could either:
- Set as a temporary measure until the system has loads of headroom to spare
or
- Have the delay kick in once critical performance metrics are exceeded and drop again as the system recovers
Bravo to you guys for the great recommendations, and cheers to Steve for reaching out to us for ideas!
Thanks FRISKIE.
If for some reason, displaying real-time data is of uber critical importance to prohashing.com, then at least delay it a minimum of 40 mins so that its offset by several mined blocks.
This code should be fairly easy to implement compared to all of the other types of suggestions and could be the path of least resistance to happiness.
If the system is still as unstable as it is now after trying this change, then at least we have ruled out the possibility that nicehash bots were the cause of issues in the first place.
There seems to be a real issue at the moment where pool operators can't seem to detect issues that miners are complaining of. Can't fix something you can't see right?
Since there are only two people operating and developing the pool, I was thinking to just try the easy stuff first to see if that makes a difference.
Steve mentioned a software database upgrade that he feels might end all the problems.
But on a ethical level, I still think pool operators ought to still strive to provide guidelines for mining etiquette in order to pave the way for a sustainable future.
If for nothing else at all, try delaying or changing profit data to avgs just as a troubleshooting exercise to see if that improves pool performance!
Re: Status as of Monday, July 31, 2017
Posted: Mon Jul 31, 2017 8:30 pm
by FRISKIE
I still think pool operators ought to still strive to provide guidelines for mining etiquette in order to pave the way for a sustainable future
Absolutely!
We are witnessing a situation where miners with a large enough war-chest have taken over NH and now abusing it in ways that have destroyed both fun and profit for all the rest.
@ Steve - it is imperative that you look at how NH/bots have moved beyond the realm of clever programming and keen miners out of a profit . .
This handful of powerful miners are out for domination (forgive the melodrama
FRISKIE
Re: Status as of Monday, July 31, 2017
Posted: Tue Aug 01, 2017 12:17 am
by vinylwasp
wkying79 wrote:vhmanu wrote:100x times fast sounds great
*fingers crossed*
A possibility to handle those burst NH rentals (bots): Is is possible to delay wamp data by amount x? With this bots would be useless.
And your normal NH renter does not get hurt
Yes! I also like this idea and had suggested a variation of it seeing how the Nicehash rental market has becoming dominated by bots tied to real-time pricing data.
I believe hashrate volatility and its "abuse" can be defeated and/or smoothed out by only displaying and outputing only
= "average profitability over 1 hour" for both pool algo and all coins.
It seems that very large amounts of hashrate exist outside of machine miner owners (such as on nicehash), and if those hashrates are being used in unstructured and "abusive" manners, then only broadcasting "average hourly" profitability data for pool and coins might level all the nonsense out.
encouraging aggressive and desructive mining behavior will end the game all too quickly for all of us.
These ideas are kind of an expansion of Greg Harding's original suggestion to take out API data when traffic is high.
I believe this solution if implemented would result in:
- less hashrate volatility due to less jumps in aggressive bot driven rentals (which account for significant hashrate traffic and spikes)
- more profit due to overall mining pool being stabilized from the input side
- higher profit margins mean more income for pool operator
- less profits for nicehash as it is in their interest to see people rent hash at higher rates
- encourage better mining etiquite and lay the stage for a long lasting ecosystem based on stability, NOT aggressiveness
I don't have the proof or the background, but i think overall in for all large systems, optimal rates for growth are achieved via stability and equilibrium of input and output stages.
I don't see why the realm of mining wouldn't also be governed by the same law of numbers that seem to be universal.
As the mining operators, you guys actually have a role and potential responsibility to create conventions now that will lead to a long term industry that doesn't eat itself up.
My 2 satoshis.
I agree that this should work if you remove the data from the webpage as well or convert it to a 1 hr delayed binary image format as opposed to browser rendered graph. As a full-time PH miner the only graph I really watch is the daily profits spread, that tells me all I need to know every 24 hours so I wouldn't miss the live feed at all.
Of course with my hacker hat back on, I'd try to pull the price, diff, and block data for a representative group of coins (the most common mined) from another source and attempt to predict profits that way. Much harder but could be done.
Removing all sources of real-time data is definitely easier than penalizing the behavior.
Re: Status as of Monday, July 31, 2017
Posted: Tue Aug 01, 2017 7:50 am
by Steve Sokolowski
A few comments before I get back to finishing up the testing of the latest release.
I see our role as providing great service to our customers. That means that we should fix bugs in our mining server, on our website, in the trading code, and so on. We should answer support tickets and help customers. We should add coins and deal with splits like Bitcoin Cash.
However, it's not our responsibility to deal with NiceHash and their business. I don't think we should be spending our own time making modifications because it affects how NiceHash's prices are or how easy it is to use NiceHash. The only part where NiceHash should become a concern to us is if people using their servers overload ours, which is what we're already striving to improve. Once our server overload problem is resolved, I have difficulty justifying a reason why we should pay any attention to conditions on NiceHash.
Re: Status as of Monday, July 31, 2017
Posted: Tue Aug 01, 2017 7:58 am
by FRISKIE
Steve Sokolowski wrote:A few comments before I get back to finishing up the testing of the latest release.
I see our role as providing great service to our customers. That means that we should fix bugs in our mining server, on our website, in the trading code, and so on. We should answer support tickets and help customers. We should add coins and deal with splits like Bitcoin Cash.
However, it's not our responsibility to deal with NiceHash and their business. I don't think we should be spending our own time making modifications because it affects how NiceHash's prices are or how easy it is to use NiceHash. The only part where NiceHash should become a concern to us is if people using their servers overload ours, which is what we're already striving to improve. Once our server overload problem is resolved, I have difficulty justifying a reason why we should pay any attention to conditions on NiceHash.
Says the obtuse mule
For me the last hope was a favorable response to exactly those recommendations - enough Steve, good luck mate, I'm out.
- FRISKIE
Re: Status as of Monday, July 31, 2017
Posted: Tue Aug 01, 2017 8:38 am
by Steve Sokolowski
FRISKIE wrote:Steve Sokolowski wrote:A few comments before I get back to finishing up the testing of the latest release.
I see our role as providing great service to our customers. That means that we should fix bugs in our mining server, on our website, in the trading code, and so on. We should answer support tickets and help customers. We should add coins and deal with splits like Bitcoin Cash.
However, it's not our responsibility to deal with NiceHash and their business. I don't think we should be spending our own time making modifications because it affects how NiceHash's prices are or how easy it is to use NiceHash. The only part where NiceHash should become a concern to us is if people using their servers overload ours, which is what we're already striving to improve. Once our server overload problem is resolved, I have difficulty justifying a reason why we should pay any attention to conditions on NiceHash.
Says the obtuse mule
For me the last hope was a favorable response to exactly those recommendations - enough Steve, good luck mate, I'm out.
- FRISKIE
I understand if you need to leave, and I wish you luck.
But our first concern is our customers, here. In an ideal world, we would love to correct NiceHash's problems, but given current conditions, the best we can do is to make our system work great with the time we have. There's a huge difference between making our system stable and making their markets stable. If we hire someone or have more time, then we will certainly look into what is best for stabilizing markets at NiceHash.
Re: Status as of Monday, July 31, 2017
Posted: Tue Aug 01, 2017 9:03 am
by FRISKIE
But our first concern is our customers, here.
My own parting comment (feel free to have the last word) - I have personally concluded that your refusal to address NH abuse is weird and dodgy.
Over to you Steve >>>
Re: Status as of Monday, July 31, 2017
Posted: Tue Aug 01, 2017 9:37 pm
by vinylwasp
Steve Sokolowski wrote: The only part where NiceHash should become a concern to us is if people using their servers overload ours, which is what we're already striving to improve. Once our server overload problem is resolved, I have difficulty justifying a reason why we should pay any attention to conditions on NiceHash.
Steve, I tend to agree with your perspective. If you feel that you can maintain sufficient blue-sky capacity across the system to handle massive swings in hash rate why would you bother to think about where it is coming from and turn away business.
But like a bar owner who has a stable group of locals who keeps the lights on, you need to ensure that the exuberant stag party that just crashed through the door don't upset your loyal customers to the degree that they start leaving, and in doing so damages your long term revenue stream.
I'm sure you've started thinking about this, but you will need to monitor the shipping dates of each batch of L3+s, A5's, etc, and develop a scaling road map which plans for steady capacity growth based on current customers expanding and replacing inefficient kit, new customers that want to make PH their local, and larger and larger volumes of swing miners as the universe of available hashing power expands in all directions (incl NH).
I don't envy you. Miners are not following Moore's Law, in some cases we're seeing 10x increases in Hashrate between generations (e.g. new X11 ASICs), so you're going to need to develop your plan carefully across software and hardware architectures.
Like throwing a happy hour in the bar context, I do think you should consider whether enticing the swing miners to mine on PH is 'good business' given the potential downsides, but that's a business decision only you and Chris can make.
Re: Status as of Monday, July 31, 2017
Posted: Wed Aug 02, 2017 6:51 am
by Sunegg
vinylwasp wrote:Like throwing a happy hour in the bar context, I do think you should consider whether enticing the swing miners to mine on PH is 'good business' given the potential downsides, but that's a business decision only you and Chris can make.
I sooo agree vinylwasp. I suggested weeks ago that PH should consider blocking NH traffic if they cannot handle the swings in hashing power. We have a ton of L3+ coming in and under current circumstances we are hesitant to using PH and I guess we are not alone. So PH may miss out on massive volumes of robust, stable hashing power in exchange for "daytrading" nicehashers that may go away any day.
But as you said, that's a business decision Steve and Chris have to make.