Yes, the 43M one is odd, but I remember like a month ago when we got the first wave of <45Ms, most of them were in fact DC candidates, and as I recall, we're still not sure why PrimeNet assigned them as DC candidates. That's something that has as yet gone unsolved. (I don't know why that one is still held by GPU272.)

I remember there was a discussion about PrimeNet server confusing TF factors with P-1 factors, for bigger factors which fall over its TF-limit cutoff. I can not find that discussion, maybe someone can point me to it. I have looked in related threads (p95, gimps, server, etc) but at the end the factors I found in the last time were done under gpu-2-72 project, so I decided to post here. My dilemma is like that:

I have reported
[CODE]
Manual testing 30946609 F 2012-03-07 13:17 0.0 541996012842777321943 3.6199
Manual testing 30946441 F 2012-03-07 13:17 0.0 370279690461888625657 2.5581
Manual testing 30987637 F 2012-03-07 07:36 0.0 310149215308792133399 2.0615
Manual testing 30603973 F 2012-03-06 17:10 0.0 480678252080857673159 3.3221
Manual testing 30037489 F 2012-03-01 15:34 0.0 319103639527297121881 2.2084
Manual testing 30939407 F 2012-03-01 11:41 0.0 314781084386270804327 2.1060
Manual testing 30938429 F 2012-03-01 00:33 0.0 567188230459976620057 3.7475
Manual testing 30566929 F 2012-02-29 18:37 0.0 351439136952867720439 2.4425
Manual testing 30958133 F 2012-02-29 15:49 0.0 383911472785050228289 2.6578
Manual testing 30917287 F 2012-02-29 15:49 0.0 569839859834256833551 3.7631
Manual testing 30565753 F 2012-02-27 11:54 0.0 476887570104844591409 3.3039
Manual testing 30565627 F 2012-02-27 11:54 0.0 379975074935690511911 2.6629
Manual testing 30954299 F 2012-02-26 02:06 0.0 340900192216659318823 2.3271
[/CODE]but...
[CODE]Manual testing 30924497 F-PM1 2012-03-06 11:13 0.0 325158435139110861601 1.3727
[/CODE]What is the mystery? They were all found by mfaktc and reported "by hand", it is not related to size of the expo, size of the "k", size of the factor, time of day, etc. Then is related to what? (I deliberately selected the expos above, in the same range, having about the same size of the factors, being reported at different times, etc).

I don't care about 1.5 GHz-day credit difference, but I know there is some dilemma about this and maybe I can cast a spark... :P

We've known for sometime that it's only a PrimeNet issue, and only fixing PrimeNet will fix the issue. We're mostly just waiting for James to [URL="http://www.mersenneforum.org/showthread.php?p=290902#post290902"]setup a WIMP environment[/URL], but as you can see he's having trouble.

Thanks Dubslow, that discussion is what I was looking for.

[QUOTE=Dubslow;292305]We're mostly just waiting for James to [URL="http://www.mersenneforum.org/showthread.php?p=290902#post290902"]setup a WIMP environment[/URL], but as you can see he's having trouble.[/QUOTE]Sorry :redface:

The good news, however, is that I've successfully set up a WIMP->LAMP wrapper, so I'm now able to work through the code. I've made good progress so far, but I haven't worked though to the manual_results section yet. Out of curiosity, I want to look through that code and figure out why TF-PM1 credit gets mixed up, but honestly I'll probably just replace much of that code with the results parser from [url=http://mersenne-aries.sili.net]mersenne-aries.sili.net[/url] since I know that works well.

[QUOTE=LaurV;292301]What is the mystery?[/QUOTE]Excellent question, good example. I'll look at the code and let you know. :smile:

[QUOTE=James Heinrich;292321]but honestly I'll probably just replace much of that code with the results parser from [url=http://mersenne-aries.sili.net]mersenne-aries.sili.net[/url] since I know that works well.[/QUOTE]

Oooohh, will that also make it as fast as your site, or is the speed more a hardware or (WI) thing?

[QUOTE=LaurV;292301]What is the mystery? [/QUOTE]

I noticed that my factors were usually just "F" when the "factor found" line was surrounded by "no factor found ... mfakto ..." lines.

I just recently submitted a single "factor found" result without preceeding "no factor" lines, and that became a "F-PM1" again.

But I do not find enough factors to validate this observation.

[QUOTE=Bdot;292374]I noticed that my factors were usually just "F" when the "factor found" line was surrounded by "no factor found ... mfakto ..." lines.

I just recently submitted a single "factor found" result without preceeding "no factor" lines, and that became a "F-PM1" again.

But I do not find enough factors to validate this observation.[/QUOTE]
This could be a very interesting observation! I remember I submitted a single factor exactly once! But I do not bet is the factor in cause, or another. But very good observation! I will watch for it.

[QUOTE=Bdot;292374]I noticed that my factors were usually just "F" when the "factor found" line was surrounded by "no factor found ... mfakto ..." lines.

I just recently submitted a single "factor found" result without preceeding "no factor" lines, and that became a "F-PM1" again.

But I do not find enough factors to validate this observation.[/QUOTE]

I did a similiar thing, I pulled the factor found lines out before the spider uploaded and put them in a file which I manually uploaded thinking I could get the correct credit. They were credited as P-1's. If I had submitted the entire file rather than edit those out, they would have been credited as TF.

[QUOTE=Bdot;292374]I just recently submitted a single "factor found" result without preceeding "no factor" lines, and that became a "F-PM1" again.[/QUOTE]You've more-or-less got it. After looking quickly through the current code, it goes something like this (simplified, leaving out many details):[code]if (previously_found_mfaktco_nofactor_lines AND length(factor) <= 23) {
handle_as_TF_factor()
} else if (exponent < 16,000,000) {
if (factor_bits > 55) {
handle_as_ECM_factor()
} else {
handle_as_TF_factor()
}
} else {
if (factor_bits < default_tf_limit(exponent)) {
handle_as_TF_factor()
} else {
handle_as_PM1_factor()
}
}[/code]The key point, it seems, is to make sure that there's at least one mfaktc/mfakto non-factor line in the submitted results (it doesn't actually matter if it comes before or after the factor line). This puts the results-parser into "mfakt[co]-mode" where it will accept large factors as TF. Otherwise any factor over the default TF limit will be assumed to be P-1.

Hmm... doesn't seem to be code that actually reads what the results lines are saying. Presuming your code does that, then I vote for that.