- Every night, I have been releasing minor fixes that seem to be increasing stability incrementally. Last night, the fixes resolved a memory leak and dealt with a problem that was causing miners to be overpaid in some cases. Tonight will be a performance improvement that should significantly reduce the time required to calculate the most profitable coin every time new economics data is received. Eventually we will reach a point where the system will be stable enough that these fixes can be made weekly or only when the next major release occurs.
- There is a problem that causes about 0.3% duplicate shares when mining Monacoins and Litecoins. I know of a fix to it and will deploy the fix tonight.
- The website has remained largely unchanged while we have made improvements to the backend. As a result, the "Last Found Blocks" table is becoming less useful, since we have miners assigned to so many easy coins. I was thinking of changing this table or adding a new table of "Last Valuable Found Blocks." Comments welcome.
- I'm investigating whether there is some way for the pool itself to work around kires's problem of miners failing over to other pools, rather than users having to set the flag. It could be that the issue is indicative of some problem that should be addressed but of which we are not aware.
Status as of Wednesday, April 29
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.
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.
- Steve Sokolowski
- Posts: 4585
- Joined: Wed Aug 27, 2014 3:27 pm
- Location: State College, PA
Status as of Wednesday, April 29
Here's today's status:
Re: Status as of Wednesday, April 29
I'm seeing my hashrates as stable for the first time since I've been using the site - which I'm very appreciative of.Steve Sokolowski wrote:Here's today's status:
- Every night, I have been releasing minor fixes that seem to be increasing stability incrementally. Last night, the fixes resolved a memory leak and dealt with a problem that was causing miners to be overpaid in some cases. Tonight will be a performance improvement that should significantly reduce the time required to calculate the most profitable coin every time new economics data is received. Eventually we will reach a point where the system will be stable enough that these fixes can be made weekly or only when the next major release occurs.
- There is a problem that causes about 0.3% duplicate shares when mining Monacoins and Litecoins. I know of a fix to it and will deploy the fix tonight.
- The website has remained largely unchanged while we have made improvements to the backend. As a result, the "Last Found Blocks" table is becoming less useful, since we have miners assigned to so many easy coins. I was thinking of changing this table or adding a new table of "Last Valuable Found Blocks." Comments welcome.
- I'm investigating whether there is some way for the pool itself to work around kires's problem of miners failing over to other pools, rather than users having to set the flag. It could be that the issue is indicative of some problem that should be addressed but of which we are not aware.
Any thoughts about a more mobile-friendly UX? Perhaps instead of a table like that, you could expand the pie chart for a particular coin when clicked on to drill down to the blocks and blockfinders for that particular coin and remove the component from the first displaying page altogether? Fewer elements to load if you aren't interested in drilling down...
I've added the "failover-only": true, statement to my bfgminer config and the results (on the titan) and pretty spectacular. My graphs look solid here and on the console now. Not sure this needs immediate attention? @kires?
- Steve Sokolowski
- Posts: 4585
- Joined: Wed Aug 27, 2014 3:27 pm
- Location: State College, PA
Re: Status as of Wednesday, April 29
I've already thought about the user interface a lot, and some people have sent comments about it.
The answer is that first, I want to get multiple merge mining working. We can merge mine at least six more coins simultaneously. Then, I want to finish testing the Comkort exchange. Increasing profitability always has to come first.
After that, the plan is indeed to significantly revamp the website. We need to change most of the graphs because a lot of them don't make sense when we make the transition to multiple algorithms. For example, a "hashrate" chart doesn't mean much if you just add the pool's hashrate from all miners together when there are multiple algorithms being mined. Multiple algorithms also requires the concept of "workers," which already exists in the system but is not yet displayed.
As June approaches, I'll probably be sharing diagrams and asking for assistance from you and others, if you're willing to help. I figure that if I post one every day, then perhaps after about 30 days we'll come to a design that satisfies most miners' needs.
The answer is that first, I want to get multiple merge mining working. We can merge mine at least six more coins simultaneously. Then, I want to finish testing the Comkort exchange. Increasing profitability always has to come first.
After that, the plan is indeed to significantly revamp the website. We need to change most of the graphs because a lot of them don't make sense when we make the transition to multiple algorithms. For example, a "hashrate" chart doesn't mean much if you just add the pool's hashrate from all miners together when there are multiple algorithms being mined. Multiple algorithms also requires the concept of "workers," which already exists in the system but is not yet displayed.
As June approaches, I'll probably be sharing diagrams and asking for assistance from you and others, if you're willing to help. I figure that if I post one every day, then perhaps after about 30 days we'll come to a design that satisfies most miners' needs.
Re: Status as of Wednesday, April 29
I've been mining two years plus and I've mined everywhere. Not a single pool, in my experience, puts nearly the effort into the pool as you guys do - kudos for that. Given what you wrote above, clearly we can all wait for the bells and whistles particularly when it comes to improvements in payouts - so merged mining and additional exchange integration should always come as top priority. I'm always available to help out with anything you all need. I'm a tech professional (as are most miners, I suppose) but I have extensive linux admin skills and can help with day to day tasks as well if you need the assistance. Further, I ran my own P2Pool with 6 merged coins for the last month or so before coming back here - so I have some experience with that as well.Steve Sokolowski wrote:I've already thought about the user interface a lot, and some people have sent comments about it.
The answer is that first, I want to get multiple merge mining working. We can merge mine at least six more coins simultaneously. Then, I want to finish testing the Comkort exchange. Increasing profitability always has to come first.
After that, the plan is indeed to significantly revamp the website. We need to change most of the graphs because a lot of them don't make sense when we make the transition to multiple algorithms. For example, a "hashrate" chart doesn't mean much if you just add the pool's hashrate from all miners together when there are multiple algorithms being mined. Multiple algorithms also requires the concept of "workers," which already exists in the system but is not yet displayed.
As June approaches, I'll probably be sharing diagrams and asking for assistance from you and others, if you're willing to help. I figure that if I post one every day, then perhaps after about 30 days we'll come to a design that satisfies most miners' needs.
As far as small ideas that would take little or no effort - I'd love to be able to append the username with a '.' and a rig designation so I can see what rigs are struggling without having to remote to a console and have a look. Low hanging fruit
Re: Status as of Wednesday, April 29
I'm happy as can be with the fact that it's working properly at long last. One question, though. How did you add it to bfgminer, by the web interface or ssh?rootdude wrote: I've added the "failover-only": true, statement to my bfgminer config and the results (on the titan) and pretty spectacular. My graphs look solid here and on the console now. Not sure this needs immediate attention? @kires?
Re: Status as of Wednesday, April 29
I used the manual edit function and added that statement below the scrypt statement. Easy as pie.kires wrote:I'm happy as can be with the fact that it's working properly at long last. One question, though. How did you add it to bfgminer, by the web interface or ssh?rootdude wrote: I've added the "failover-only": true, statement to my bfgminer config and the results (on the titan) and pretty spectacular. My graphs look solid here and on the console now. Not sure this needs immediate attention? @kires?
EX:
],
"scrypt-n": 10,
"failover-only": true
}