Bad profit

I finally fixed the issue that was causing the revised server to fail to start. Of course, as seems to be the case with all difficult bugs, it was caused by a single-character spelling error. I had named a directory with a "_" instead of a "-" as the server was expecting.

I have deployed the updated code and it is currently running on the server. I am monitoring it now to see what effects the change has had. If it works as planned, profits today should improve dramatically, although they won't be optimal for a few days. We will have more orphaned coins since selfish mining is disabled, and it will take a few days for the orphan rates to adjust so we will again be mining an optimal mix of coins.

Steve will be working today to determine the underlying issue that causes selfish mining to reduce profitability. I will keep everyone updated as we make progress.

Also, I wanted to mention that in this new code, we have fixed an unrelated issue that was causing the server to be unable to obtain prices for some YoBit markets. The is caused by a limitation of YoBit's API. In YoBit's API, you have to specify every market for which you want the price in the API call. However, YoBit has an undocumented limit of 512 characters for the API query. We had added so many YoBit markets that our API calls had become longer than 512 characters and were failing. We now execute multiple API calls to obtain market prices. As a result, about 20 coins are no longer in error for being unable to obtain a price. Being able to mine these coins will also improve profitability.

Which would be better to use for a difficulty settings on my asics. I normally set my machines difficulty manually using the d=4096 ect.. Should I be using the setting d=??? and also a h=100 setting or is one better to use then the other and should I not set both? If I do a h=100 should I just use p=x.. I want to get the best efficiency but it seems if I do not set a high difficulty my machines switch coins a lot and my overall hash rate becomes unstable and low. I guess I just need some clarification on the h= compared to the d= for best performance?
I have
A2 110Mhs
Gblacks (2) 24Mhs
gridseed blades (3) 5.3Mhs

Thanks!

Steve and I did a lot of research today, and we determined that the changes we made yesterday did not resolve the issue, and in fact, we will be reverting the changes. However, we did discover the root cause of the issue and made a change to fix it. We will have more details in the morning. Unfortunately, that will mean that today's earnings won't be great, but tomorrow's earnings should be about 15-20% higher.

Regarding the miners, we designed the h= parameter if you are using a cloud mining service that penalizes you for work restarts. It excludes coins below the given coin difficulty. The d= parameter is a static share difficulty, which is designed so miners submit shares at a regular rate. A high d= parameter will effectively work the same as h= and exclude coins with low difficulty, since you can't mine coins with a difficulty lower than your share difficulty. For your information, share_difficulty/65536=network_difficulty, so if you set d=262144, that's effectively the same as h=4. However, with d=262144, you will submit shares very infrequently, it may be a few minutes per share, and we may disconnect you for submitting no shares. If you want to limit work restarts, set d= so that you submit a share about every 10 seconds then set h= to a point where you aren't getting too may work restarts.

In my opinion, you shouldn't be getting low hashrate with your miners directly connected to the pool; this indicates a bug in our system. Let me know which workers those are and I will investigate what is happening with them. Our goal is that you shouldn't have to manually set anything to get optimum hashrate, so if you do have to set something, then our mining server has a bug.

Chris Sokolowski wrote:Steve and I did a lot of research today, and we determined that the changes we made yesterday did not resolve the issue, and in fact, we will be reverting the changes. However, we did discover the root cause of the issue and made a change to fix it. We will have more details in the morning. Unfortunately, that will mean that today's earnings won't be great, but tomorrow's earnings should be about 15-20% higher.

Regarding the miners, we designed the h= parameter if you are using a cloud mining service that penalizes you for work restarts. It excludes coins below the given coin difficulty. The d= parameter is a static share difficulty, which is designed so miners submit shares at a regular rate. A high d= parameter will effectively work the same as h= and exclude coins with low difficulty, since you can't mine coins with a difficulty lower than your share difficulty. For your information, share_difficulty/65536=network_difficulty, so if you set d=262144, that's effectively the same as h=4. However, with d=262144, you will submit shares very infrequently, it may be a few minutes per share, and we may disconnect you for submitting no shares. If you want to limit work restarts, set d= so that you submit a share about every 10 seconds then set h= to a point where you aren't getting too may work restarts.

In my opinion, you shouldn't be getting low hashrate with your miners directly connected to the pool; this indicates a bug in our system. Let me know which workers those are and I will investigate what is happening with them. Our goal is that you shouldn't have to manually set anything to get optimum hashrate, so if you do have to set something, then our mining server has a bug.

Looking better but only if I set a d= number. I tried setting no difficulty on my A2 and then after a bit it stopped submitting shares. I changed it to d=4096 and seemed to fix it

Do you know what difficulty it was automatically assigning you? I wanted to know whether the server is erroring too high or too low.

This issue has been resolved - please see http://forums.prohashing.com/viewtopic.php?f=4&p=3250

Chris Sokolowski wrote:This issue has been resolved - please see http://forums.prohashing.com/viewtopic.php?f=4&p=3250

It was changing the difficulty all over the place depending on the coin

OK I can say for sure now my A2 Mega does not like being set with no static difficulty. If I set it on dynamic it kills the hashrate from 103Mhs down to 80-85Mhs on some coins and the pool assigns it 32768 and it also raised the restart times


5 minutes later the A2 is back around 106Mhs assigned diff of 65536

30 mins later Mega looking much better restart still a tad high I will give it some more time