Status as of Saturday, July 8, 2017

Good morning! Here's a few ideas for today:

• Chris had problems rebooting one of the servers on Thursday when he installed the Intel 960 Pro solid state disks. It turns out that the GRUB bootloader depends on devices being in a specific order. When he turned the computer off, he was unable to get it to recognize that there was a Debian partition even after he removed the new disks. It took him many hours to resolve the issue, and for that we apologize. Fortunately, the installation of the disks puts us in a great position for permanently eliminating the share delay load issues that were due to the disks being unable to respond in time.
• We archive share data every four weeks. Since we released the latest code on July 4, that means that on August 1, we will be able to move the database to the new fast disks without having to bring over the data we no longer need. However, Chris will be on vacation in Ottawa and Montreal, so we'll wait until the weekend of August 12-13 to perform that move. It will probably result in 3 hours of downtime.
• There were reports last night of a large number of connections to the mining server. My theory is that some sort of Internet connectivity problem caused miners to connect and disconnect repeatedly, leaving half-open connections and causing server overload. We'll investigate if that happens again.
• The next weak link in the performance chain is the share inserter's CPU load. While the database will be able to handle almost any load after the new disks are commissioned, the inserter is now reaching high CPU loads at times, which delay shares. I'll be working on that this weekend.
• SHA-256 mining remains on hold indefinitely. We aren't going to release it until we reach a point where we have so much extra capacity that we can't make any other use of it. Right now, every time we fix another performance problem, more miners join, so there's no reason to complicate the system with SHA-256. After the bubble crashes and we can get a better idea of how the long-term profitability will be, then we can decide whether to hire someone to work full time on performance improvements to get to SHA-256.

works like a charm right now.... during the event my Alchemyst miner would be disconnected every 2 vblocs and then display zero shares yet all the time... while it was finding shares and the balance updated correctedly anyway..... now all feels reaaly more fluid... Thanks this summer looks terrific!

Steve Sokolowski wrote:Good morning! Here's a few ideas for today:

• Chris had problems rebooting one of the servers on Thursday when he installed the Intel 960 Pro solid state disks. It turns out that the GRUB bootloader depends on devices being in a specific order. When he turned the computer off, he was unable to get it to recognize that there was a Debian partition even after he removed the new disks. It took him many hours to resolve the issue, and for that we apologize. Fortunately, the installation of the disks puts us in a great position for permanently eliminating the share delay load issues that were due to the disks being unable to respond in time.
• We archive share data every four weeks. Since we released the latest code on July 4, that means that on August 1, we will be able to move the database to the new fast disks without having to bring over the data we no longer need. However, Chris will be on vacation in Ottawa and Montreal, so we'll wait until the weekend of August 12-13 to perform that move. It will probably result in 3 hours of downtime.
• There were reports last night of a large number of connections to the mining server. My theory is that some sort of Internet connectivity problem caused miners to connect and disconnect repeatedly, leaving half-open connections and causing server overload. We'll investigate if that happens again.
• The next weak link in the performance chain is the share inserter's CPU load. While the database will be able to handle almost any load after the new disks are commissioned, the inserter is now reaching high CPU loads at times, which delay shares. I'll be working on that this weekend.
• SHA-256 mining remains on hold indefinitely. We aren't going to release it until we reach a point where we have so much extra capacity that we can't make any other use of it. Right now, every time we fix another performance problem, more miners join, so there's no reason to complicate the system with SHA-256. After the bubble crashes and we can get a better idea of how the long-term profitability will be, then we can decide whether to hire someone to work full time on performance improvements to get to SHA-256.

Steve,

During this upcomming release, can we please have the Workername of the worker who got the share which solved the blocks allocated to the useraccount published? This is valuable information to me as I am sure it is to other people who share rigs etc. Currently it will show your solved blocks but unless you have set a different static difficulty on every miner I cannot think of another way presently of identifying which machine or group of machines achieved this from within PH.

Secondary question, is there any support planned in the future for having multiple addresses for a single coin type? Say you wanted to split the money between two wallets for security or in a shared miner circumstance?

Also tertiary question, are matured credited solomined blocks included in the total income bars?

Thank you for everything!
Tmopar

The next weak link in the performance chain is the share inserter's CPU load. The ''next weak'' or the next ''week''?

mickeekung wrote:The next weak link in the performance chain is the share inserter's CPU load. The ''next weak'' or the next ''week''?

"weak link"

tmopar wrote:

Steve Sokolowski wrote:Good morning! Here's a few ideas for today:

• Chris had problems rebooting one of the servers on Thursday when he installed the Intel 960 Pro solid state disks. It turns out that the GRUB bootloader depends on devices being in a specific order. When he turned the computer off, he was unable to get it to recognize that there was a Debian partition even after he removed the new disks. It took him many hours to resolve the issue, and for that we apologize. Fortunately, the installation of the disks puts us in a great position for permanently eliminating the share delay load issues that were due to the disks being unable to respond in time.
• We archive share data every four weeks. Since we released the latest code on July 4, that means that on August 1, we will be able to move the database to the new fast disks without having to bring over the data we no longer need. However, Chris will be on vacation in Ottawa and Montreal, so we'll wait until the weekend of August 12-13 to perform that move. It will probably result in 3 hours of downtime.
• There were reports last night of a large number of connections to the mining server. My theory is that some sort of Internet connectivity problem caused miners to connect and disconnect repeatedly, leaving half-open connections and causing server overload. We'll investigate if that happens again.
• The next weak link in the performance chain is the share inserter's CPU load. While the database will be able to handle almost any load after the new disks are commissioned, the inserter is now reaching high CPU loads at times, which delay shares. I'll be working on that this weekend.
• SHA-256 mining remains on hold indefinitely. We aren't going to release it until we reach a point where we have so much extra capacity that we can't make any other use of it. Right now, every time we fix another performance problem, more miners join, so there's no reason to complicate the system with SHA-256. After the bubble crashes and we can get a better idea of how the long-term profitability will be, then we can decide whether to hire someone to work full time on performance improvements to get to SHA-256.

Steve,

During this upcomming release, can we please have the Workername of the worker who got the share which solved the blocks allocated to the useraccount published? This is valuable information to me as I am sure it is to other people who share rigs etc. Currently it will show your solved blocks but unless you have set a different static difficulty on every miner I cannot think of another way presently of identifying which machine or group of machines achieved this from within PH.

Secondary question, is there any support planned in the future for having multiple addresses for a single coin type? Say you wanted to split the money between two wallets for security or in a shared miner circumstance?

Also tertiary question, are matured credited solomined blocks included in the total income bars?

Thank you for everything!
Tmopar

Hi Tmopar,

Blocks are included in the income bars no matter how they are mined, but because solo-mined blocks take so long to mature, they won't always be included in the same day as they are found. Sometimes, they will be confirmed and credited the next day.

The issue of storing worker names for solved blocks is something that we've thought of for years, but it would require significant rework to do that because of the way electricity calculations are implemented. They were implemented incorrectly and should be per-worker. Once we can separate out electricity calculations per worker, then it's a cinch to record which worker obtained the share.

The multiple addresses issue was asked for once before, but because only two customers have asked for it, it's far down the list, behind profitability and stability and performance improvements. I'd love to promise you that we will implement it, but it's more likely that there will always be something more pressing.

Thanks,

-Steve

To: Steve Sokolowski

Pool x11 without functioning Dash is not a Pool!

bbbbbbb wrote:To: Steve Sokolowski

Pool x11 without functioning Dash is not a Pool!

I'm not sure what you mean. I looked just now and didn't notice any problems with Dash. Perhaps I'm missing something?

If I am, feel free to contact Chris at the contact E-Mail address and he'll be happy to look into it.

any thoughts for MUI on x11 pool?