Ecosystem/gupaxx
1
0
Fork 0
mirror of https://github.com/Cyrix126/gupaxx.git synced 2024-11-16 15:27:46 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions

feat: add rules note for algorithm to integrate outside hashrate.

Browse source
This commit is contained in:
Cyrix126 2024-03-26 21:22:28 +01:00
parent e9d8d37ad2
commit 6f841b8217
1 changed files with 28 additions and 6 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

34
NOTES_ALGORITHM.md
View file

@ -27,7 +27,13 @@ Every ten minutes, the algorithm will decide how next 10 minutes will be distrib
## Manage with outside HashRate
Gupaxx could be connected to a xmrig proxy to control HR of every miners outside local machine.
If miners outside the Gupaxx instance are mining on P2pool for the same address, Gupaxx will send too much on P2pool because it doesn't take extra HR outside his control into account.
To solve this issue, it will look at the sidechain estimated HR (eHR) from status command of p2pool. It is an estimation based on passed discovered shares, their difficulty, the number of blocks between them etc...
This eHR will be retrieved at the same interval as the algorithm.
This estimated external HR(eHR) minus the local HR sent to p2pool will be removed from the mHR.
If miners outside the Gupaxx instance are mining on XvB for the same address, Gupaxx will maybe send too much (more than enough for the round) or too less (could have been in better round) on XvB.
To solve this second issue, it will remove from the required HR to get to rounds the average HR sent to XvB (retrieved by XvB API) minus what he is sending of its own.
## Examples
@ -50,16 +56,32 @@ The first round type (Donor round) need 1kH/s and second round type (VIP Donor)
5kH/s is enough for the Donor Round but not enough for the VIP Donor.
So 1kH/s is given to XvB node so that the miner participate in the Donor round.
**Hero mode**: 4 minutes are given to p2pool and 5 for XvB.
**Hero mode**: 4 minutes are given to p2pool and 6 for XvB.
### Example 3: the hardworker
Miner has 5kH/s on Gupaxx
He also have one remote miner that mines 2kH/s on P2pool and another one 8kH/s on XvB
**Default mode**: 6 minutes are given to p2pool and 4 for XvB.
Because to have at still one share per window, gupaxx need to complete the already existent HR on p2pool with 4 minutes (2kH/s). But after that, it still have 6 minutes spared (3kH/s) when only 4 minutes are needed to gain the better round of vip donor (10kH/s). So it will send only the necessary 4 minutes to XvB and give the 2 minutes not needed to p2pool.
**Hero mode**: 4 minutes are given to p2pool and 6 for XvB.
## Technical Implementation
### Knowing if a share is in PW
P2pool node (PN) local API show only found shares and not current. It is not also showing the current height block of p2pool.
Gupaxx process will check every minute when a new share is found, and how much time passed since the last. While verifying if mining on mini or main chain, it will calculate if the last share found is still valid.
This way Gupaxx will know if a share is currently in the window.
This method is only an estimation, a better way would be to know at which block the share is found and which block height the network is currently at. But P2pool API doesn't offer these information by API but by command.
P2pool node (PN) local API show only found shares and not current.
Gupaxx process will check frequently the output of the p2pool command "status" without impacting the console output of the P2pool tab to get the current shares.
### know oHR on P2pool
Gupaxx watch for sidechain HR for his address on the output of status command of p2pool in a way that do not disturb the output of console in the UI.
### know oHR on XvB
Gupaxx receive these data from XvB API.
### Knowing the HR generated by Gupaxx