GPU to 72 status...

[Dubslow]

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.)

[LaurV]

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

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

but...

Manual testing    30924497    F-PM1    2012-03-06 11:13    0.0    325158435139110861601    1.3727

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

[Dubslow]

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 setup a WIMP environment, but as you can see he's having trouble.

[LaurV]

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

[James Heinrich]

Originally Posted by Dubslow

We're mostly just waiting for James to setup a WIMP environment, but as you can see he's having trouble.

Sorry

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 mersenne-aries.sili.net since I know that works well.

Originally Posted by LaurV

What is the mystery?

Excellent question, good example. I'll look at the code and let you know.

[Dubslow]

Originally Posted by James Heinrich

but honestly I'll probably just replace much of that code with the results parser from mersenne-aries.sili.net since I know that works well.

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

[Bdot]

Originally Posted by LaurV

What is the mystery?

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.

[LaurV]

Originally Posted by Bdot

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.

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.

[bcp19]

Originally Posted by Bdot

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.

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.

[James Heinrich]

Originally Posted by Bdot

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

You've more-or-less got it. After looking quickly through the current code, it goes something like this (simplified, leaving out many details):

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()
  }
}

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.

[Dubslow]

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.