HDD mining with Linux on burstcoin. We want to do mining with HDD on burst coins with a linux. At this point we have to install miner and start mining in the. Easiest Way To Mine Peercoin PPC more.

Stale shares are the shares that were sent after a block was already solved, that is to say, they were sent late and were no longer valid. To avoid stale shares, best to have a reasonably fast mining rig (so you won't take too long to calculate a share, probably not a problem for most machines), reliable internet connection (stable, not necessarily fast), but also an up-to-date mining software (if you are mining with some really old miner it might not communicate in the most efficient manner with the pool). In short - update your miner every now and then, make sure your internet is running okay, and don't mine on really weak rigs. A stale share occurs when you find a share and submit it to the mining pool after the pool has already moved on to the next block. The percentage of stale shares should be very low if everything's working correct, around 2 out of 1,000 shares or so. Several factors affect the stale share rate. The three most important are long polling, pool load, and miner-to-pool latency.

Any shares found based on old work units after the pool controller receives a new block will be stale. Long polling is a technique that allows the pool to notify all of its miners when there's a change in the block chain so they can immediately request new work units. If your pool or mining software doesn't support long polling, you will finish out the old work units, generating stale shares. When the long polling notification goes out, all miners that support long polling request new work units at about the same time. This generates a massive burst of load as the pool has to manages lots of network traffic and do several SHA-256 operations for each share it issues.

If the pool is slow to issue you a new work unit, the window in which you can generate stale shares increases. The long polling and subsequent share request process requires a few network operations. Latency between the miner and the pool can slow this process down. Picking a pool with a controller near you (network wise) can reduce this part of the stale share window as well. DigitalNote XDN Mining Hardware Requirements there. In addition, some pools have had bugs in their software that produced stale shares.

The pool checks if the share is stale by seeing if it has a record of the work unit and clearing all work unit records when the chain changes. So if something goes wrong with the work unit tracking process, that will result in a stale share being reported. For example, if the pool erroneously issues the same work unit to two miners, the first one to submit the share will get credit. The pool will remove the record when the share is found because otherwise you could submit the same share more than once. This will result in you getting a stale share report. I probably shouldn't admit it, but I was actually responsible for one such bug.

My first implementation of long polling in the Bitcoin client rushed as quickly as possible to send out the notifications of a new block being discovered to miners -- so quickly that some miners could request new work units before the client had finished processing the new block and they got work units based on the old block. Any shares they submitted based on those work units would be reported as stale.

The above answers are good but one thing I would add is that hashing rate affect stale share%. Because with a faster miner a smaller% of shares are even 'at risk' of being stale. Pools only pay for completed shares. A block is found on average every 10 minutes so in that 10 minute window the last share is the one at risk of being stale. Now the time between blocks varies but is 10 minutes on average so we will just look at affect of hashing power in a 10 minute window. A 100MH/s miner would complete (on average) one share every ~42.9 seconds. Which means in 10 minutes it could complete ~14 shares.

A 800MH/s miner would complete one shares 5.36 seconds. In 10 minutes that is ~112 shares. If both miners are working properly and connected to fast accurate pools at most they will lose one share. In other words for the slow miner 1 in 14 shares are 'at risk' while with the fast miner only 1 in 112 shares are at risk. The far extreme of this would be trying to mine with a slow CPU.

Your hashing rate could be so slow that on average you only complete 1 share per 10 minute block. So 100% of your shares are at risk of being stale. Everything else being equal a faster miner is more efficient putting less shares at risk of being stale. Note: for this purpose only the single GPU hashing power matters not the total rig or farm hashing power.

I don't agree. The window where a stale share can be found begins when the pool controller sees a new block and ends when the miner has a new work unit through long polling. The size of this window is dependent only on network latency and pool load and is totally independent of the miner's hashing power.

You are correct that the percentage of shares 'at risk' varies, but that doesn't matter because as the percent of risk goes up, the level of risk per share goes down. (The slow miner has all his shares at risk, but very low risk since the danger window is a tiny fraction of the mining time.) – Oct 11 '11 at 15:18.

• • • • Here is how to install and run creepminer on ubuntu (or debian) linux os. Here i tryied to arrange and put in order the documentation found online, after tried the installing by myself. This miner is better than burstminer, more configurable and uptodate, so i recommend it.

Install basic build tools: apt-get install build-essential Install git if not already present in OS: apt-get install git Install OpenSSL and SSL library development headers: apt-get install openssl apt-get install libssl-dev Install cmake: apt-get install cmake Clone the repository: git clone Change the directory: cd creepMiner Run the POCO install script (it will download and install POCO for you): sh./install-poco.sh If you want to use your GPU, install the (or OpenCL; remember: CUDA has OpenCL already included). Apt install nvidia-cuda-toolkit Create your makefile using cmake (use this ): for CPU + GPU: cmake CMakeLists.txt for CPU only: cmake CMakeLists.txt -DNO_GPU=ON for SSE2 only: cmake CMakeLists.txt -DMINIMAL_BUILD=ON Make the miner: make The binary file will be in./bin Now you have to setup mining.conf config file. In particular set the mining pool, wallet address and plots path.

Here we suggest to use that is advanced and well done mining pool for burst coins. Dont forget that, before using the pool, you have to do the reward assignment to address published by the pool. Do see how to do, please look.