Status as of Saturday, July 15, 2017

Discussion of development releases of Prohashing / Requests for features
Forum rules
The Development forum is for discussion of development releases of Prohashing and for feedback on the site, requests for features, etc.

While we can't promise we will be able to implement every feature request, we will give them each due consideration and do our best with the resources and staffing we have available.

For the full list of PROHASHING forums rules, please visit https://prohashing.com/help/prohashing- ... rms-forums.
Post Reply
User avatar
Steve Sokolowski
Posts: 4585
Joined: Wed Aug 27, 2014 3:27 pm
Location: State College, PA

Status as of Saturday, July 15, 2017

Post by Steve Sokolowski » Sat Jul 15, 2017 8:15 am

Hi! Here's today's status:
  • Chris will be moving the share data to the fast disks today. The goal of this action is to reduce the number of times the share inserter gets more than 30s behind. Note that the inserter will always get behind at times because of confirming found blocks, which takes out locks on the tables that are needed for share insertion, but delays of many minutes should be rare after this one.
  • We're aware of times when there are large numbers of rejected shares. They occur because of CPU overload. The only thing I can say about these is that we're continually working on improving performance and get a few percent more every weekend.
  • Chris fixed a major issue where coins would go into permanent error state if 30 blocks had been found and the coin daemon lost network connectivity for more than 1s. This issue caused reduced profits and disconnected static coin miners. Feel free to offer you thoughts on this one if it recurs.
  • Chris found and fixed a major issue that caused some people to earn litecoins or larger proportions of other coins. It turns out that ccex, which has been under DDoS attacks, implemented some sort of protection method that delays incoming connections by 10s before serving requests. However, our timeout for API calls was set at 10.01s, so there was rarely enough time to obtain all the pricing data from ccex. Coins listed only at ccex would go into error, and coins whose prices were best at ccex would be mined suboptimally. This issue has been fixed by setting the timeout to 30s.
  • I plan to publish a comprehensive argument as to why Segwit2x should be opposed on Monday, to convince miners to switch to pools that oppose it.
  • Today's tasks include investigating why f_all_balance_updates returns bad data and improving performance.
User avatar
FRISKIE
Posts: 117
Joined: Sun Apr 16, 2017 12:51 pm

Re: Status as of Saturday, July 15, 2017

Post by FRISKIE » Sat Jul 15, 2017 9:40 pm

I plan to publish a comprehensive argument as to why Segwit2x should be opposed on Monday
Definitely looking forward to this one. .

Oh my dear heavens, could we really be looking at a BTC chain split afterall? As in, split = 2 x bitcoin (ala ethereum style)

Interesting days indeed!
Post Reply