Hi all,
I’ve just added a GPU to my rig (an AMD card on a previous full Nvidia rig) and switched from TRex to PhoenixMiner.
The hashrate has increased but the number of valid shares is almost the same. See the screenshot below.
Is there any explanation for this?
You are probably solving higher difficulty blocks ? Just a guess.
Suddenly only more difficult blocks, just after the new card added?
Someone with more knownledge may correct me, but I think the hiveON pool auto adjusts the difficulty based on how much hashing power you have.
But yes it does seem a bit annoying that you add more cards and the submitted shares can go down.
Best to just double check your estimated earnings with the hiveon.net esitmate per 100MH, or some online calculator like whattomine
Yes, looking at the pool homepage my results for 200MHs are ok, according to their 100MHs estimate.
It looks weird that the number of shares is almost the same as before…
Vardiff explained
What is it and why is it needed?
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.
How does it work?
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 “target share difficulty” - 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.
How does this affect my reward?
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 (“initial”) 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.
Vardiff vs Stale shares
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.
Example
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.
5 Likes
Thank you for the detailed explanation.
Really appreciated
This topic was automatically closed 416 days after the last reply. New replies are no longer allowed.