A mining pool is the grouping of resources by miners, who share their processing power, hashrate, over a network, to split the reward equally, according to the amount of work they contributed to the probability of finding a block. A "share" is awarded to members of the mining pool who present a valid partial proof-of-work.
A share is a hash smaller than the target for difficulty that's usually lower than the network difficulty. Every hash generated has a chance of being a valid share. Miners have no control over when they will generate a share as they occur randomly. When one miner in the pool finds the solution hash, the rewards can then be split by number of shares submitted by each miner. There are multiple reward methods, PPLNS, PPS, PPS+, etc. These reward types calculate the "fair share" of the reward, but all pools use a share as a "proxy" for work completed by each miner. A share has no actual value. The only hash worth something is the one that solves a block. A share is just a method to divide any rewards earned by the pool.
A hashrate (or hash rate) is the measure of a miner’s performance. It is the speed at which a miner solves a task. Hash per second represents SHA-256 algorithms that are used per second, known as hash rate. The hash per second, H/s, is the measure of the efficiency of the miner. Higher hash rate means increased chances of receiving a block reward.
Reported Hashrate is used by mining software to determine the submitted computed hashrate of the hardware to the pool. The reported hashrate is essentially used for comparing it to your calculated hashrate shown by the pool. Reported hashrate is generally inaccurate and that's why there's always a small difference when comparing it to the calculated hashrate. It is a value only displayed by your workers' mining software.
Mean or Calculated hashrate is calculated from the accepted hashes that your hardware has submitted to the pool. This value can fluctuate above or below your reported hashrate. The rate is impacted by such things as stale shares, invalid shares, changing hash difficulty and pool's luck. Your worker may submit more or less shares during a given period of time that are accepted by the pool.
Average is exactly what it's called – an average. This is the average effective hashrate over a specified period of time. The higher the better.
Usually there is a somewhat significant difference between reported hashrate and average hashrate. This is considered normal, so don't worry about the reported hashrate too much. The higher the reported rate, the better is the average hashrate. But keep in mind, if you push your workers too hard then the calculated hashrate will take a plunge creating a gap between reported and calculated. That will affect your payouts.
The hashrate on the pool is calculated from the number of decisions made by the pool for a certain unit of time, and displays the average value. Keep in mind that not all decisions sent by your worker are correct or arrive on time. It depends on the quality of the connection and speed (Ping). The less the ping is, the faster the pool will receive decisions from your worker. Therefore, it is less likely that the solution will not be relevant, and the pull will not reject it. Thus, the speed displayed on the pool will be closer to that displayed on the dashboard. But it will always be a little lower.
The effective miner hashrate on the pool is different since only accepted and stale shares are taken into account.
Each pool operates on a different set of rules for their payouts, but here are a few of the most popular ones:
Pay-per-share (PPS), is a reward system where the miner will receive a reward (get paid) for each valid contributed share. PPS pools are considered to be the best reward types if you want a steady 100% (minus the pool fee) income. PPS pools pay for literally every valid share you submit. Meaning, every time your mining software “accepts” a transaction, you get rewarded with a small amount regardless of whether the pool has found a block or not. The pool operator is virtually hiring your hash power.
Pay Per Last N Shares (PPLNS) is a payout type in which the miner takes the risk of variance upon himself. PPLNS pools were designed to stop "pool hoppers" as they don’t technically pay out the current block, but instead they pay out based on an average of the shares that were submitted over the last x number of blocks. So, when first starting to mine on a PPLNS pool, one will notice that they'll hardly get paid anything until a few hours later. This will ramp up over time and once one stops mining, they'll still get paid for a few hours, due to the “buffer effect” of PPLNS.
PPS+ (Pay per Share Plus) is a combination of the PPS and PPLNS payout methods. Just like with PPS, miners are paid for each share that they submit, giving them a predictable payment method. Unlike PPS, which only awards block rewards and does not cut tax fees, PPS+ distributes all bonuses to miners and splits all rewards above the block. While the fluctuating rewards like in the PPLNS are avoided as a whole.
It's a metric that shows how many shares the pool needed in order to find a block relative to the average number of shares needed for finding a block. If the luck is above 100% then the pool needs less shares then expected for a given difficulty. If the luck is below 100%, then more shares were needed. Luck only shows the history of the pool and cannot be used to predict future blocks. Finding a block is completely random, so joining a pool when there is high luck and then leaving when the luck is low, won't make any sense.
For the best quality of working with the pool, it is best to use the server with which you have the fastest connection. You can check it with the
Ping command. The lowest value will show the fastest connection. Also, we recommend specifying multiple servers. If the main server crashes, your ASIC will automatically switch to the spare one and avoid downtime.
Unlike most PPLNS pools, which use static difficulty, HiveOn uses variable difficulty (vardiff). This ensures network traffic optimization between your workers and the pool. The Pool assigns higher difficulty tasks to higher tier miners and lower difficulty tasks to lower-tier miners so that the average communication frequency is roughly the same throughout all miners.
Although the "vardiff" concept may seem difficult to understand, it is only at first glance. Let's take a closer look at how this works.
The Mining Pool sets a Share Difficulty for every miner based on your workers’ hashrate (sets the difficulty bar - how hard it is to submit a share to them). The higher the hashrate, the higher the Share Difficulty. When miners are grinding through hashes, they will eventually find a hash that meets the target Share Difficulty, then they send it to the Mining Pool.
In a PPS based payment method (Hiveon uses PPS+, you can read about it here), miners get rewarded by the pool for each share they submit. The shares they submit have different values based on how difficult it is to find them. Miners get credited based on the set Share Difficulty from the Mining Pool, not the actual share difficulty.
When the worker starts a mining session, the pool sets the base difficulty which is equal for all workers (currently 5000MH on Hiveon ETH/ETC pool). After receiving a certain amount of shares during the handshake period and also on a time-to-time basis if shares are sent too quickly or too slowly to the pool, the pool then determines what difficulty is most optimal for any given worker. If the worker sent shares too quickly it means that they can handle more difficult jobs and the difficulty will be raised (15000MH maximum), if on the other hand, it sent shares too slowly, the difficulty will drop (1000MH minimum). So while the sent shares count may be similar across different workers, the share difficulty will most likely be different.
Too high difficulty shares on weaker workers are one of the culprits that cause stale shares. Vardiff ensures an even rate of shares transfer, less server load, and fewer stale shares for the client. In short, it can help solve such issues because a stale share can occur when you find a share and submit it to the mining pool after the pool has already moved on to the next block.
And finally, let's look at this through a basic example:
Let's say you have 2 workers, RIG A & RIG B.
RIG A has a total of one GPU @ 50 MH/s. The Mining pool sets the Share Difficulty for this worker @ 1250MH. You then, get credited by the pool for all shares that are above 1250MH.
RIG B has a total of 100 MH/s. The Mining pool sets the Share Difficulty for this worker @ 2500 MH.
Both RIG A & RIG B will have approximately the same number of shares sent, but RIG B will receive double the revenue from the pool for the higher difficulty submitted shares.