Quote from: Biodom on February 03, 2018, 05:23:03 AM

Quote from: kano on February 03, 2018, 05:19:57 AM

Quote from: Biodom on February 03, 2018, 05:08:39 AM

First off, I allowed for difficulty change as I specifically mentioned in my post.

Second, no way our numbers for January are those that are currently on the website.
As you say, they will be adjusted once the first block in February is found.
I expect the number at around 100%, maybe even lower, but NOT 116%.
116% number was there since the last block and it did not budge the week (or so) without blocks.
I fail to see the relevance of this number in such case.

The January number wont change.

As I said, it shows the stats for blocks found in January - not the hashing done in January.
The code works as: any block with a date of the month of interest, then it's numbers are included in the calculation for a given month.
The hash rate is easy:
Elapsed = from the time of the last block of the previous month to the time of the last block of the current month.
Hashes done = total hashes of each of the blocks in the month (including invalids before them of course)
Hash rate = Hashes done / Elapsed

The next block found will be in February, so that wont affect the January numbers.

OK, I think I finally got it.
Thanks for the detailed explanation, it was helpful.

I also find the current Monthly Statistics confusing/not relevant. According to january:

Code:

---------------------------- Monthly Statistics ----------------------------
UTC Month Pool Avg Blocks Expected Mean Diff% MeanTx% CDF[Erl] Luck% PAPPS%
2018 January 31.98PHs 8 6.87 85.86% 132.04% 0.3817 116.47% 152.40%

what was the number of blocks expected for January? 6,87 ---> Looks like wrong, as the rest of the data for January.

This system of calculating only for last block is showing best luck possible calculated just when block is won. In the case of January it shows to be a extreme case. Of course January has been an very unlucky month... but.. it will always show green (good luck month) historically to the user giving "wrong" quick look information.

Last row (current month) in Monthly Statistics should be calculated daily, at my point of view, with a cron job so it doesn't give every day (except the day when block is found) "uncorrect" info for the month, as it is happening now.

Calculating last row daily would probide exactly the on-going stasts and the final stats for the month. That is, in my oppinion more useful for the user than the info linked to the moment when las block was won. In fact, for me knowing what happened in January, those Monthly Statistics, would seem to be wrong, if I would not know that they are linked to the last block won (in this month case skipping the last almost 10 days (1/3 of the month) BAD LUCK)... and well... As said, even knowing the related "trick" these stats for me seem to provide no use for the specific and extreme case of January.

I am not critisising, I am just sharing my point of view, because I would like a change there... to the daily Monthly Statistics's last row update cron task approach. That would make me happy! :-)