Credit for trial factoring
 

I have just TF an exponent in the range 71:72 and found a factor.
However the only credit I received was:
CPU credit is 0.6650 GHz-days.
I did factor the whole of the exponent, so I would have thought the minimum I would have received would have been 7.0282 GHz-days which is what I received for the previous TF which did not find a factor.

Are found factors being credited differently now? :confused:

P95 does the [U]trial[/U] (not trail :P) factoring by testing the candidates in increasing order. If your factor is at the beginning of the range (i.e. 2^71+k, with a very small k), you may find it in the first minute, or in the first second. Why should you get billions of credit for just few seconds of work? :razz:

When GPUs came into the pool, the logic shifted, the range is divided in modularity classes, and the candidates in each class are processed in parallel using the multitude of cores the GPU has. Therefore, you may be lucky and find a very big factor (close to 2^72) in the first class, in 5 seconds, or work one day, and find a very small factor (close to 2^71), in the last class you crunch.

PrimeNet is not (yet) aware of GPUs, as I said so many times here.

He will give you the credit according with the size of the factor, assuming you found it with P95. It is not possible otherway, without introducing the possibility of cheating (you find a factor with one program, but report it with the other, to get more credit).

So, in the last case described above, you will get small credit for a lot of work, or in the former case described, you will get a huge credit for just few seconds of work.

You were unlucky this time.

LaurV is correct. It will all even out eventually, though.

LaurV and I are what you might call credit whores, but I still attribute more value to "factors found" than "GHz-Days" of credit.

To add on to what LaurV said, you will never receive as much credit for a TF factor as for a non-factor test, as the factor found cannot be above the range searched. The credit should always be between the (using yours as an example) credit from 70-71 and the credit from 71-72 with no factor. In other words, you get more than the previous full bit's credit but less than the current "full bit" depth credit.

[QUOTE=TheMawn;366765]
LaurV and I are what you might call credit whores, but I still attribute more value to "factors found" than "GHz-Days" of credit.[/QUOTE]

Damn right :razz:

[SIZE="1"](*poke* *poke* LaurV)[/SIZE]

[QUOTE=c10ck3r;366767]To add on to what LaurV said, you will never receive as much credit for a TF factor as for a non-factor test, as the factor found cannot be above the range searched.[/QUOTE]

To add on to what c10ck3r said, this is true for Primenet. On GPU72 you get the full credit for the range the factor was found in. As in, if you were assigned work for a candidate from 71 to 74, and found a factor which was at 72.1, you'll get the GHz/D credit for TFing from 71 to 73.

My thinking was (and is) that since the goal of TF'ing is to find factors, those successful should get the full credit for the range they worked up to (and I have no way of determining if the range was fully tested, or only partially. Primenet has this knowledge (or, at least, is told); I don't).

[QUOTE=c10ck3r;366767]To add on to what LaurV said, you will never receive as much credit for a TF factor as for a non-factor test, as the factor found cannot be above the range searched. The credit should always be between the (using yours as an example) credit from 70-71 and the credit from 71-72 with no factor. In other words, you get more than the previous full bit's credit but less than the current "full bit" depth credit.[/QUOTE]
This is not accurate. LaurV was right.

Perhaps this will help clarify:
No factor from 70-71 grants 3.5 GHz-days
A factor in the 70-71 range grants 0-3.5 GHz-days, depending on how long it would've taken Prime95 to find it.
No factor from 71-72 grants 7.0 GHz-days
A factor in the 71-72 range grants 0-7.0 GHz-days, depending on how long it would've taken Prime95 to find it.

Mfaktx searches for factors in a different order than Prime95, meaning sometimes you can do 99% of the work and get 1% of the credit (which is roughly what happened this time), but on the flipside you could find a factor at the 1% mark and get 99% of the credit. In the long run, it averages out so that you get as much credit as you worked for.
This is assuming you have Mfaktx configured to stop after you find a factor. You can search the rest of the bit range if you like, but PrimeNet won't credit you for it, because it's outside PrimeNet's main scope. If you do continue to search, you'll always do 100% of the work for (average) 50% of the credit when finding a factor (since factor found results are a minor portion of your overall TF credit, this is actually pretty insignificant).

Is that primenet bug fixed that would calculate the credit as if it was a F-PM1 (factor found by P-1)?

OTOH, so far I NEVER got less credit for a factor than for completing a bitlevel with NF. Typically, I'd say, it is 100-200% of the credit of an NF for the same range.
As in
[code]
INFO: M65531953 submitted; 29.1922 GHz Days credit. (73 -> 74)
INFO: M65459887 submitted; 29.2243 GHz Days credit. (73 -> 74)
INFO: M65771899 submitted; 14.5428 GHz Days credit. (72 -> 73)
INFO: M65771527 submitted; 14.5429 GHz Days credit. (72 -> 73)
INFO: M65771899 submitted; 37.8749 GHz Days credit. (73.3 bit factor)
INFO: M65772071 submitted; 14.5428 GHz Days credit. (73 -> 74)
[/code]or
[code]
INFO: M65532281 submitted; 14.5960 GHz Days credit. (72 -> 73)
INFO: M65531317 submitted; 29.1925 GHz Days credit. (73 -> 74)
INFO: M65531933 submitted; 29.1922 GHz Days credit. (73 -> 74)
INFO: M65531461 submitted; 14.5962 GHz Days credit. (72 -> 73)
INFO: M65532281 submitted; 29.1920 GHz Days credit. (73 -> 74)
INFO: M65531951 submitted; 25.4500 GHz Days credit. (72.7 bit factor)
INFO: M65532283 submitted; 14.5960 GHz Days credit. (72 -> 73)
INFO: M65531953 submitted; 14.5961 GHz Days credit. (72 -> 73)
INFO: M65531461 submitted; 29.1924 GHz Days credit. (73 -> 74)
INFO: M65532283 submitted; 29.1920 GHz Days credit. (73 -> 74)
[/code]

I've had the same experience as bdot.

So I wasn't hallucinating ....:smile:

[QUOTE=Bdot;366885]Is that primenet bug fixed that would calculate the credit as if it was a F-PM1 (factor found by P-1)?

OTOH, so far I NEVER got less credit for a factor than for completing a bitlevel with NF. Typically, I'd say, it is 100-200% of the credit of an NF for the same range.
As in
[code]
INFO: M65531953 submitted; 29.1922 GHz Days credit. (73 -> 74)
INFO: M65459887 submitted; 29.2243 GHz Days credit. (73 -> 74)
INFO: M65771899 submitted; 14.5428 GHz Days credit. (72 -> 73)
INFO: M65771527 submitted; 14.5429 GHz Days credit. (72 -> 73)
INFO: M65771899 submitted; 37.8749 GHz Days credit. (73.3 bit factor)
INFO: M65772071 submitted; 14.5428 GHz Days credit. (73 -> 74)
[/code]or
[code]
INFO: M65532281 submitted; 14.5960 GHz Days credit. (72 -> 73)
INFO: M65531317 submitted; 29.1925 GHz Days credit. (73 -> 74)
INFO: M65531933 submitted; 29.1922 GHz Days credit. (73 -> 74)
INFO: M65531461 submitted; 14.5962 GHz Days credit. (72 -> 73)
INFO: M65532281 submitted; 29.1920 GHz Days credit. (73 -> 74)
INFO: M65531951 submitted; 25.4500 GHz Days credit. (72.7 bit factor)
INFO: M65532283 submitted; 14.5960 GHz Days credit. (72 -> 73)
INFO: M65531953 submitted; 14.5961 GHz Days credit. (72 -> 73)
INFO: M65531461 submitted; 29.1924 GHz Days credit. (73 -> 74)
INFO: M65532283 submitted; 29.1920 GHz Days credit. (73 -> 74)
[/code][/QUOTE]

This is a known bug, low on the priority list, though with the Web site renovations, it might just finally get some attention.