Accepted hashrate
Forum rules
Welcome to the System Support forum! Encounter a problem related to the pool? Post your issue here and we will help you out.
Keep in mind that the forums are monitored by PROHASHING less closely than the official support channels, so if you have a pressing issue, please submit an official support ticket so that our Support Analyst can look into your issue in a timely manner.
We cannot answer financial questions related to your account on a public forum, so those questions should always be submitted through the orange Support button on prohashing.com/about.
For the full list of PROHASHING forums rules, please visit https://prohashing.com/help/prohashing- ... rms-forums.
Welcome to the System Support forum! Encounter a problem related to the pool? Post your issue here and we will help you out.
Keep in mind that the forums are monitored by PROHASHING less closely than the official support channels, so if you have a pressing issue, please submit an official support ticket so that our Support Analyst can look into your issue in a timely manner.
We cannot answer financial questions related to your account on a public forum, so those questions should always be submitted through the orange Support button on prohashing.com/about.
For the full list of PROHASHING forums rules, please visit https://prohashing.com/help/prohashing- ... rms-forums.
Re: Accepted hashrate
I'll know with greater certainty tomorrow morning, but for now it looks like this latest fix had a stabilizing effect on my hashrate. What was it, exactly that was changed?
Re: Accepted hashrate
Looks like I spoke too soon. Sorry about that, but it looks like I was looking at too small a dataset. Still no joy.
-
Steve Sokolowski
- Posts: 4585
- Joined: Wed Aug 27, 2014 3:27 pm
- Location: State College, PA
Re: Accepted hashrate
Well, we did make some progress. I fixed one problem and another was uncovered. Eventually, we'll be able to resolve all the issues.
What's been happening for days is that we have a database that essentially serves as an accounting system, and there are thousands of checks in the database to cause errors in the system when an action would create a problem. For example, there were two buys this morning that were attempting to be executed against coins we supposedly don't own. The trader was prevented from executing the trades until Chris can determine why there is a problem.
In this case, the problem is that the proportions of miners mining certain coins is totaling greater than 1. This morning, the system thought it was mining litecoins 100.001% of the time, which obviously isn't possible. Yesterday, it thought it was mining monacoins -6 x 10^-17 percent of the time. These errors are caused by floating point addition and subtraction. We had thought we could use floating points to store hashrates, but it turns out that we were wrong, for this reason. With floating points, addition and subtraction don't necessarily result in the same result; you can perform 0.0 + 2.0 - 2.0 and end up with 5.7 x 10^-15, instead of zero.
Today, I'm going to convert the floating point hashrates to decimals, which take up more disk space and require more CPU power, and then see if the system performs adequately. With decimals, Decimal(0.0) + Decimal(2.0) - Decimal(2.0) = Decimal(0.0) all the time. This change might require downtime to convert a billion rows in the database, so I'll keep you updated on if any downtime is needed to fix this.
We are not adding any new features to the mining server at this point, in order to focus solely on these bugfixes to make the system as stable as possible. I think that we made too much money last night because of these errors. If it turns out that we did, I will have Chris pay you and other miners for the difference.
What's been happening for days is that we have a database that essentially serves as an accounting system, and there are thousands of checks in the database to cause errors in the system when an action would create a problem. For example, there were two buys this morning that were attempting to be executed against coins we supposedly don't own. The trader was prevented from executing the trades until Chris can determine why there is a problem.
In this case, the problem is that the proportions of miners mining certain coins is totaling greater than 1. This morning, the system thought it was mining litecoins 100.001% of the time, which obviously isn't possible. Yesterday, it thought it was mining monacoins -6 x 10^-17 percent of the time. These errors are caused by floating point addition and subtraction. We had thought we could use floating points to store hashrates, but it turns out that we were wrong, for this reason. With floating points, addition and subtraction don't necessarily result in the same result; you can perform 0.0 + 2.0 - 2.0 and end up with 5.7 x 10^-15, instead of zero.
Today, I'm going to convert the floating point hashrates to decimals, which take up more disk space and require more CPU power, and then see if the system performs adequately. With decimals, Decimal(0.0) + Decimal(2.0) - Decimal(2.0) = Decimal(0.0) all the time. This change might require downtime to convert a billion rows in the database, so I'll keep you updated on if any downtime is needed to fix this.
We are not adding any new features to the mining server at this point, in order to focus solely on these bugfixes to make the system as stable as possible. I think that we made too much money last night because of these errors. If it turns out that we did, I will have Chris pay you and other miners for the difference.
Re: Accepted hashrate
Let me know when the update is rolled out so I can point one back here ASAP. Also, than-q.
-
Steve Sokolowski
- Posts: 4585
- Joined: Wed Aug 27, 2014 3:27 pm
- Location: State College, PA
Re: Accepted hashrate
This issue should be resolved now. I converted all the floats to Decimals.
Also, there was a longstanding bug fixed that I'll review in the "development" forum soon.
Also, there was a longstanding bug fixed that I'll review in the "development" forum soon.