se o capito correttamente piu il numero e basso meglio è
Lo score è un valore in millisecondi, calcolato in base al valor LRT (last round time): più basso= più veloce.
Se sei curioso:
Technical details of PTS mining/understanding yvg1900's M7h version of jhProtominer (from the developer, yvg1900)
Now let us think on the structure of the work what is miner doing. It is split by "nonce rounds".
Every round consists of generating merkle root and iterating throgh "nonces", trying to find pairs of "nonces" that produce same "birthday" according to PoW. So rounds are independent from each other.
Whithin single round at the beginning chances of finding pair is zero = think of that we are looking at 1st nonce, which has no pair - then there is truely zero chances if it is pairing with the other.
Longer round goes, more chances to find pair - that is what we call collision. Maximum chances to find pair is right at the end of the round. This is the nature of "momentum" PoW.
Under CPM we calculate Collisions Per Minute, which is actually our rate of finding pairs. Now let us think of hos CPM function will look within single round. How CPM function : your CPM is zero at the beginning of the round, and max is at the end and the whole chart of CPM across multiple rounds is saw-shaped, with saw bottoms at the end, and saw tops at some value. We are trying to measure average CPM, that depends on the saw slope and temporal distance between teeth.
Now let us turn to something completely different. Let us think of block times and round times. PTS block rate target is 5 minutes, but because of poorly designed difficulty management it is actually 2-2.5 times faster. I estimate for myself PTS block rate of once per 2 minute. If you take 3-hour stat from ypool - open stats - you will see a block once per 2.1 minute. So our REAL block rate is approx. 1/2 blocks a minute, i.e. 2 minutes per block.
Now let us see our LRT, which stands for "Last Round Time". LRT is measured in milliseconds and NOT rounded or averaged. It is just sampling LAST one as it recorded. What are your LRT values? They range from 4 sec (which is really fast) to 15 sec.LRT value measured PER THREAD, because of every thread is executing separate round. Now let us change to completely other area - "f" vs "s" vs "combined termination in M7h". I hope you understand is that any calculations on old block after new one arrived make absolutely no sense. Do you? I refer calculations made that way as "wasted calculations". So "f" version was never checking if new block arrived during the round, only between rounds. "s" version was checking that every time collision candidate found which is times more often than no checks at all, but still rare M7h "checks" that virtually every nonce. Which means M7h stops waster calculation as fast as possible.
Now let us think of side effects and how these "cuts" reflect on the function of CPM over time. Imagine you cut the last "tooth" at the end of the block (also having in mind that CPM value within the block grows non-lineary, but approx. ^2 of the intra-block time). This means that by early termination you "cut" significant part of your CPM that was formerly contributed by "wasted calculations". If you think block arrival is random function and CPM round slope is non-linear (^2). You can calculate which part of last round's CPM contribution to average you actually cut I estimate this as 80%. And you cut that - listen (!) - times your thread count! Because of when now block arrives ALL your worker threads early-fail.
Now let us estimate how many rounds we have per block. Given 2 minutes and 8 seconds LRT, you have (120/8) = 15 round per thread per block You cut off 80% of last block, so your final CPM for early-terminate algos (perfect case) will be (15-0.
= 14.2, which results in (14.2/15) = 0.94 = 94% of "displayed performance" againt "f" version means we "virtually looks" 6% of our CPM, while eliminating A LOT of wasted calculations. Now finetuning calculations set to do not count "aborted" rounds. It was a bug affecting "s" variation of M7.
