Status as of Wednesday, March 25

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.
Locked
User avatar
Steve Sokolowski
Posts: 4585
Joined: Wed Aug 27, 2014 3:27 pm
Location: State College, PA

Status as of Wednesday, March 25

Post by Steve Sokolowski » Wed Mar 25, 2015 9:30 am

A brief update on some interesting things that we found out:
  • I've spent about eight hours optimizing the mining server, and was able to cut CPU usage in half. There was a lot of inefficient code where we iterated through every coin to find the one we were looking for, and these functions were called thousands of times per second. Now, these functions use a dictionary that runs in log(n) time instead of n/2 time. For the number of daemons we have now, that means the average case requires 10 coin checks rather than 75, and those checks are faster. For the frequent occurrence when we wanted to find all the merge mined coins, the number of checks is reduced from 75 to 1.
  • We suspect that the high CPU usage was causing more shares to be stale than needed to be, because we would spend a lot of time in processing after receiving a share. Our testing indicates that there is less time spent processing shares in this next release.
  • We discovered a memory leak that currently exists that was based on the faulty assumption that all blockchains quickly advance, so old blocks fall out of memory and are cleaned up. With some daemons, nobody is mining them and therefore all the merge mined blocks are kept in memory for all time, since every merge mined block is referenced in every primary block. We changed that to only retain some constant number of merge mined blocks. We think the correct number is 2, but we'll start with a maximum of 10. That reduces memory usage from 6GB to about 400MB.
  • Chris came up with a significant finding. We've known that a large number of the orphaned blocks are orphaned by ourselves, but what he found is that many of the blocks are being submitted by the same miners. In the case of confessioncoins, one miner submitted 23 blocks at the same height, causing the coin to become disabled. It never occurred to me that we can reject the later 22 blocks as "stale blocks," and that has implications as to how everyone is paid out. Right now, the high orphan rate is reducing everyone's profitability because a few people with poor connections are submitting large numbers of stale blocks. By rejecting those blocks, we significantly increase everyone else's earnings, and slightly reduce the earnings of the person submitting the stale blocks.
  • We also determined that people are being paid for stale shares in many cases. The orphaned blocks issue is apparently creating a lot of profit for us, but that profit is lost to people who are submitting stale shares that aren't being rejected. We fixed that issue in the next release.
  • The gist of this update is that the next release will be more "fair" in assigning money to everyone. Profitability will increase a lot for everyone, but it will increase most for miners who have lower work restart penalties and lower latency connections.
  • Chris is still testing the work restart changes and we are on schedule to complete them soon.
slawek
Posts: 41
Joined: Thu Mar 12, 2015 8:32 pm

Re: Status as of Wednesday, March 25

Post by slawek » Wed Mar 25, 2015 1:30 pm

Sorry to ask sometimes so simple questions and wasting your time, but I'm saying is I do not know.
THANK YOU THANK YOU BROTHER ALSO
Locked