fix: Calculating scan time and space computed by BM chips

[adammwest]

What
fixes #248

started with #167

the hcn is a nonce limiter, the max value means the most space is searched, the hcn withholds bits to roll in the nonce
max seams to be 430000, but only anything over 860000 causes performance issues.
between 430000 and 860000 it does really stange things in the nonce space it creates 2 uniform parts of the nonces space,
as in the distrobution is 2 uniforms together, rather than 1.
nonces between 0-x have avg count ~ N
nonces between x-y have avg count ~ M
up to 430000, it just fills more space in in nonce byte1
nonces between 0-y have avg count ~ N
this hcn behavoir is consisitent with hcn of older chips (1384/1387)

the only applies for a single chip!

This will allow devices to have safe changes to task generation delay, and will support all freqs for those overclocking.
also starts the ground work for calulating this value for asics in a chain.

general theme is that there are multiple components to assess how much space is being scanned for a chip and at what time when the chip rolls over
each chip has a pattern due to the the amount of cores is never a multiple of 2.

then for version rolling chips you can limit the version space
then for 136X+ chips you have HCN which limits the nonce space

the idea of this PR is to
1 know the time at which duplicate space will be done, in a dynamic equation with changes to version rolls,hcn,frequency.
2 know the exact amount of maximum space being scanned for some settings, then realistic estimates of actual space can be done.

I have data to suggest the work will likely work on a bm1370
but i dont have device to test bm1370 so cant do that yet.

Generally the equation has the following components

1. version_rolls
2. nonce_percentage = chip_nonce_max * hcn_percentage * nonce_space
3. frequency
4. small_cores
5. chips (this point is less relevant as bitaxe is a single chip device)
6. time

the space equation is
FULLSCAN_percent * HCN_percent * VERSION_percent * ASIC_NONCE_percent * 2^48 for a single work item
see the variables inside the pr

the maximum HCN value is approximately 430000 or 0x68fb0 for bm1366 and bm1368
although hashrate issues will only appear at 860000 and over that number will cause internal duplicates meaning some cores will get the same work.

How
added knowledge about each chips mining characteristics
kept the default HCN values, I have used 50% scan amount for each chip
added a version_percent variable to track changes to version rolling from the pool (although that should be rare)
which updates the fullscan equation

Control
to change the fullscan amount change FULLSCAN_percent in the chip header files, if you want a specific ms
you need version rolls,hcn,freq, then the max is known, then FULLSCAN_percent is just a percentage of that max value

thinking about what default values to set here is important.
for instance increasing the HCN means you can delay work generation for longer.
Some discussion on the default fullscan time for each chip may be necessary,

Testing
I have built and tested on supra, this needs be to tested this on every device.
testing at a stock frequency and a higher frequency for each device seems desirable
for all chips
Supra , Ultra , Gamma and maybe Max

[mutatrum]

There is an off-by-one error somewhere:

I (17578) ASIC_task: ASIC Job Interval: 1812.53 ms
[...]
I (18228) create_jobs_task: Set chip version rolls 65535
I (18228) stratum_task: rx: {"params":[10000],"id":null,"method":"mining.set_difficulty"}
I (18238) create_jobs_task: Set chip fullscan 1812.498908

coming from this code in create_jobs_task.c:

            //calulate update to fullscan_ms as new version rolling
            double new_version_percent = (double)version_rolls / (double)65536.0;
            double prcnt_change = new_version_percent/GLOBAL_STATE->version_space_percent;
            GLOBAL_STATE->asic_job_frequency_ms *= prcnt_change;
            GLOBAL_STATE->version_space_percent = new_version_percent;
            ESP_LOGI(TAG, "Set chip fullscan %f", GLOBAL_STATE->asic_job_frequency_ms);

I set the BM1368_FULLSCAN_PERCENT to 1.0. The initial asic job interval is set 1/65536 shorter. Don't think that's supposed to happen?

Should it be:

            double new_version_percent = (double)(version_rolls + 1) / (double)65536.0;

Not sure where the 65536.0 is coming from? Is that the maximum it can be?

Other than that, it seems to be hashing fine with these settings on my Supra.