[QUOTE=LaurV;560298]Oh, you mean the other way around... Never tried that, because I always stop after class, but it should be easy to try, just take a factor line already reported and edit the asterisk. I will try when I reach home in about one hour (still at job).[/QUOTE]
A) what are you talking about? "edit the asterisk"?
B) shouldn't be necessary to manually intervene. What about people who use Misfit or mfloop etc.?
C) ... especially since completing the bit level is the mfaktc default configuration. (But not mfakto)
mfaktc ini file as distributed in zip file:[CODE]# Allow to split an assignment into multiple bit ranges.
# 0 = disabled
# 1 = enabled
# Enabled Stages make only sense when StopAfterFactor is 1 or 2.
# Do not change this in the middle of a run which spans over multiple
# bitlevels, in this case mfaktc will ignore the checkpoint file and
# restarts from the beginning.
#
# Default: Stages=1

Stages=1


# possible values for StopAfterFactor:
# 0: Do not stop the current assignment after a factor was found.
# 1: When a factor was found for the current assignment stop after the
# current bitlevel. This makes only sense when Stages is enabled.
# 2: When a factor was found for the current assignment stop after the
# current class.
#
# Default: StopAfterFactor=1

StopAfterFactor=[B]1[/B][/CODE]mfakto ini file as distributed in zip file:[CODE]# Allows you to split an assignment into multiple bit ranges.
# Note that many mfakto-kernels can handle only one bit level at a time,
# i.e. in order to use them, Stages needs to be enabled.
# 0 = disabled
# 1 = enabled
# Enabled Stages make only sense when StopAfterFactor is 1 or 2.
#
# Default: Stages=1

Stages=1


# possible values for StopAfterFactor:
# 0: Do not stop the current assignment after a factor was found.
# 1: When a factor was found for the current assignment stop after the
# current bitlevel. This makes only sense when Stages is enabled.
# 2: When a factor was found for the current assignment stop after the
# current class.
#
# Default: StopAfterFactor=2

StopAfterFactor=[B]2[/B][/CODE]D) Finishing the bit level makes more sense to me, because it leaves the database cleaner, with completed bit levels, not partially completed, so the folks that like to overfactor or completely factor Mersenne numbers don't need to either repeat trial factoring work already performed, or gamble by skipping part of a bit level.
E) The assignment is by bit level. Finish the assignment seems like the right thing to do.
F) The first factor found is not necessarily the smallest, since factoring on gpus is done class by class, not in ascending k order.

[QUOTE=LaurV;560298]Oh, you mean the other way around... Never tried that, because I always stop after class, but it should be easy to try, just take a factor line already reported and edit the asterisk. I will try when I reach home in about one hour (still at job).[/QUOTE]Please don't encourage submission of faked results. You really should know better than that.

In terms of GIMPS, stopping immediately after a factor is the efficient thing to do, (it's not prime, QED). Somebody might eventually extend factoring, but they're already "wasting time" (in terms of prime finding) so redoing a bit level is not unexpected. Primenet assignments are to TF from X to Y, or until a factor is found. Prime95 will not finish the bit level.

Finding factors is frequent, more than daily in my case and no doubt for some others too.
Here's another case of reduced credit for a factor found:
[COLOR=darkgreen]processing: TF factor 24706114790941063870961 for [URL="https://www.mersenne.org/M114010123"]M114010123[/URL] (2[SUP]74[/SUP]-2[SUP]75[/SUP])[/COLOR]
[COLOR=blue]CPU credit is [B]12.9969[/B] GHz-days.[/COLOR]
[COLOR=darkgreen]processing: TF no-factor for [URL="https://www.mersenne.org/M114010289"]M114010289[/URL] (2[SUP]74[/SUP]-2[SUP]75[/SUP])[/COLOR]
[COLOR=blue]CPU credit is 33.5587 GHz-days.[/COLOR]


Finding a factor is the exception, not the rule. And multiple factors in a bit level is an exception within that. Prime95 behavior is sorta moot now that almost all factoring is done on gpus, but it used to look for additional factors.

Some excerpts from whatsnew.txt:
[CODE]New features in Version 28.3 of prime95.exe
-------------------------------------------

4) Information added to result lines containing "has a factor". This information may be used
by the server's manual web page to give proper TF / P-1 / ECM cpu credit at a future date.

New features in Version 23.9 of prime95.exe
-------------------------------------------

2) A bug in continuing after finding a factor when using AdvancedFactor was
fixed.

New features in Version 20.3 of prime95.exe
-------------------------------------------

3) Prime95 no longer searches for a smaller factor when trial factoring
discovers a factor. The reasons are two-fold. 1) Version 19 had a
bug where stopping and restarting the program bypassed the search for
smaller factors. Thus, my database may already be missing smaller
factors. 2) As we factor larger exponents to a deeper depth it may
no longer be a quick job to determine if there are smaller factors.
Note, that version 20 will still look for smaller factors if you are
looking for factors below 2^60 with the FactorOverride option in undoc.txt.[/CODE]The FactorOverride seems to be gone from undoc.txt. The prime95 undoc.txt seems not to have any control for behavior upon finding a factor, or say what is the default behavior, stop upon factor, or finish the class or bit level or worktodo uppermost level. ECM retains an explicit control for finding additional factors. Single or multiple factors may be found by a single P-1 GCD in either stage 1 or 2. Some excerpts from undoc.txt:

[CODE]By default, ECM will stop when a new factor is found.
You can have ECM always stop or always continue searching for factors by
using a value of zero or one in prime.txt:
ContinueECM=n

You can force the program to skip the trial factoring step prior to
running a Lucas-Lehmer or PRP primality test. In prime.txt add this line:
SkipTrialFactoring=1

You can tune trial factoring performance with several prime.txt settings. Probably
only the first parameter below is worth tuning:
MaxTFSievePrime=x (default is 155000 on AVX512 CPUs, 145000 on FMA CPUs, 1000000 otherwise)
The TF code uses a small prime sieve to eliminate composite trial factors.
Set x to the maximum small prime used by this sieve. MaxTFSievePrime is limited
to the range of 5,000 to 100,000,000.
ThreadsPerTFPool=n (default is number of hyperthreads)
When multithreading, set n to the number of threads to group together in a "pool".
Pooling ensures that both sieving and trial factoring will be done by threads within
the same pool. Thus, if the threads share a cache, locality is increased. For example,
on Knights Landing the best setting is 8 because 2 cores with 4 hyperthreads each
share an L2 cache.
PercentTFSieverThreads=y (default is 50)
When multithreading TF, set y to be the percentage of threads in each pool that can be
running the small prime sieve. NOTE: If y is set to 100, then pooling is turned off.
That is, each thread sieves and then immediately TFs. While this offers perfect locality,
it gives slightly worse performance and I cannot explain why. My best theory is that
pooling improves usage of the instruction cache.
UseMaxSieverAllocs=0, 1, 2,or 3 (default is 3)
If UseMaxSieverAllocs is 1 then at least 7 sievers will be allocated, resulting
in a 14% reduction in single-threaded sieving. If UseMaxSieverAllocs is 2 then at
least 60 sievers will be allocated, resulting in a further 9% reduction in sieving.
If UseMaxSieverAllocs is 3 then at least 720 sievers will be allocated, resulting in
a further reduction of 7%. The downside is more memory is required and initialization
of each of the 16 factoring passes is slower. Allocating a lot of sievers can be
detremental when factoring to low bit levels.
AlternateTFSieveCount=z (default is 9)
On AVX2 and AVX512 cpus, the code can sieve for small primes using either traditional x86
instructions or using AVX2/AVX512 instructions. As sieve primes get larger, the x86 code
is faster than the AVX2/AVX512 code. Set z to the number of blocks of small primes to use
the AVX2/AVX512 code path. On my AVX2 Skylake cpu the optimal block count is 9. Using too
large a value here can result in memory corruption depending on the MaxTFSievePrime setting.[/CODE]

[QUOTE=James Heinrich;560304]Please don't encourage submission of faked results. You really should know better than that.[/QUOTE]
Nope, sorry, that wasn't my intention. I only suggested it like a "fast test". Unfortunately (or fortunately?) I didn't do anything yet, in this direction (quite busy at job, then I forgot). In case I will do this test, I will still finish the bitlevel, just to be sure I don't let the garbage in the DB. Probably later. FWIW, reporting a known factor (i.e. removing the asterisk from a line already sent and sending it again without it) doesn't work (error: factor not needed). So it needs a "new" factor for a trial.

@kriesel: All you said was clear already. We KNOW than the credit is smaller when you find a factor, IF you stop after the factor is found. And this is normal, as you do less work. The question was what's the credit if you DON'T stop (and finish all the bitlevel). You should still get all the credit, factor or no factor, but this I didn't know if true. On the other hand (and this everybody knows for ages!), the difference between two lines that report respectively "i found one factor and I stopped after that class" and "I found one factor but I still continued the rest of the classes till the bitlevel ended", is just [U]one asterisk[/U] (which you can edit with a text editor, if you want to test, or if you want to cheat the system and get more credit). That's what I (and James) am (are) talking about. Moreover, you just post some rubbish from some doc files, with no connection to the subject. Not P95 neither mfakt[c/o] gives you the credit, but the server... :razz: This has nothing to do with whatever you set in your ini files.

[QUOTE=LaurV;560344]@kriesel: All you said was clear already. We KNOW than the credit is smaller when you find a factor, [B]IF[/B] you stop after the factor is found. And this is normal, as you do less work. The question was what's the credit if you DON'T stop (and finish all the bitlevel). You should still get all the credit, factor or no factor, but this I didn't know if true. On the other hand (and this everybody knows for ages!), the difference between two lines that report respectively "i found one factor and I stopped after that class" and "I found one factor but I still continued the rest of the classes till the bitlevel ended", is just [U]one asterisk[/U] (which you can edit with a text editor, if you want to test, or if you want to cheat the system and get more credit). That's what I (and James) am (are) talking about.[/QUOTE]LaurV, you are pointlessly belaboring the other case, mfakt[B]O[/B] default, stopafterfactor=2 (stop after current class) correctly getting lesser credit, which is not at issue here. What is at issue is mfakt[B]C[/B] default stop after current[B] bit level[/B] getting credit for only stop after current [B]class[/B], incorrectly reduced.

Mfaktc separately reports the factor(s) and the [B]bit level completed[/B].

I posted an excerpt from mfaktc.ini at [URL]https://mersenneforum.org/showpost.php?p=560218&postcount=3359[/URL] showing I DO go to the full bit level regardless, as is mfakt[B]c[/B] default configuration.
And examples in [URL]https://mersenneforum.org/showpost.php?p=560303&postcount=3367[/URL] and [URL]https://mersenneforum.org/showpost.php?p=560308&postcount=3370[/URL] where doing so and finding a factor results in REDUCED credit. Also note in the first attachment of 3367, the more than an hour delay between the factor and the completion of the bit level, on an RTX2080 Super (1 of 3 instances running together).
I can back that up with logging of all classes run after the one or more that contained a factor.
[CODE]Starting trial factoring M114969319 from 2^75 to 2^76 (66.56 GHz-days)
k_min = 164300059317240
k_max = 328600118636496
Using GPU kernel "barrett76_mul32_gs"
Date Time | class Pct | time ETA | GHz-d/day Sieve Wait
Oct 18 14:58 | 0 0.1% | 5.967 1h35m | 1003.89 82485 n.a.%
Oct 18 14:58 | 5 0.2% | 5.620 1h29m | 1065.87 82485 n.a.%
...
Date Time | class Pct | time ETA | GHz-d/day Sieve Wait
Oct 18 15:35 | 1640 35.5% | 6.534 1h07m | 916.77 82485 n.a.%
Oct 18 15:35 | 1641 35.6% | 6.847 1h10m | 874.86 82485 n.a.%
M114969319 has a factor: 61735152791358058725319
Oct 18 15:36 | 1644 35.7% | 7.137 1h13m | 839.31 82485 n.a.%
Oct 18 15:36 | 1649 35.8% | 7.136 1h13m | 839.43 82485 n.a.%
...

Oct 18 16:47 | 4616 99.9% | 6.290 0m06s | 952.33 82485 n.a.%
Oct 18 16:47 | 4617 [B]100.0%[/B] | 6.689 0m00s | 895.53 82485 n.a.%
found 1 factor for M114969319 from 2^75 to 2^76 [mfaktc 0.21 barrett76_mul32_gs]
tf(): total time spent: 1h 49m 23.377s
[/CODE]In that case it gave neither 100% bitlevel credit, nor 35.6% current-class credit, but 47.1568 / 66.56 = 70.85% instead of the 100% due.

In both example cases I am also using the standard default mfaktc output format.
James has offered to look into the reduced-credit-for-full-bit-level situation which I've also emailed to him.

It ought work correctly for a default mfaktc ini file, and does not, and that is both documented, and independently confirmed.

What is not documented is the asterisk you refer to; where does it go, what does such output look like, how does it differ from mfaktc default output, what custom mfaktc format would generate it, if it's necessary for proper credit why isn't it part of the default mfaktc output format, etc. EXACTLY.

If you can hold off the urge to test things for 12h I can look at the code and see what it's doing.

Asterisk is documented. I asked for it maybe 5 years ago. Search way back in this thread somewhere.

edit: You already participated in a [url=https://www.mersenneforum.org/showthread.php?t=5758&page=128]discussion[/url] on the asterisk and bitrange completion 2.5 years ago

[QUOTE=kriesel;560349]James has offered to look into the reduced-credit-for-full-bit-level situation which I've also emailed to him.[/QUOTE]So I've looked at the manual_results code and you are indeed correct: TF credit is only given as far as where Prime95 would have found the factor. The TF-credit calculating code is somewhat buried and I'm not sure I want to mess with it, however the manual form was already detecting whether the range was completed or not so it was easy to patch in a full-credit override when a factor is found the but bitrange finished anyways.

So, somebody please find a new TF factor (while finishing the bit level) and let me know if you get appropriate full-level credit or not now.

[QUOTE=James Heinrich;560351]Asterisk is documented. I asked for it maybe 5 years ago. Search way back in this thread somewhere.[/QUOTE]After some digging I found the original suggestion, on page 113 of this (currently 306-page) thread, from 2011-Sep-27:
[url]https://www.mersenneforum.org/showthread.php?p=272893[/url]
It was soon-after included in mfaktc v0.18 and mfakto v0.10

[QUOTE=James Heinrich;560374]So, somebody please find a new TF factor (while finishing the bit level) and let me know if you get appropriate full-level credit or not now.[/QUOTE]Not. Credit still reduced. Emailing details. Thanks for your efforts, as always.


edit: But interestingly, [url]https://www.mersenne.org/results/?extf=1&exp_lo=2&exp_hi=&limit=100[/url] shows full credit, for the same factor-found line as shows reduced credit in the manual submission form results output.