[QUOTE=flashjh;289147]:redface: I checked all my P95 computers, I don't know why this happened? All have plenty of memory allocated.[/QUOTE]

That's why I asked James if it might be a Prime95 configuration (or other) issue.

So you can check, your two were:

49232621,560000,560000
49235027,560000,560000

[QUOTE=chalsall;289148]That's why I asked James if it might be a Prime95 configuration (or other) issue.[/QUOTE]
I know, but it still stinks.

[QUOTE]So you can check, your two were:

49232621,560000,560000
49235027,560000,560000[/QUOTE]

I will, thanks.

I checked all 600 P-1 that GIMPS lists for me as NF-PM1 for the last 365 days. Only 11 of them had B2 slightly below 10M. The minimum during my GPU-2-72 time was
[SIZE=2]45952603[/SIZE][SIZE=2] NF-PM1[/SIZE][SIZE=2] 2011-12-26 20:49 [/SIZE][SIZE=2]0.0[/SIZE][SIZE=2] B1=440000, B2=8800000[/SIZE]
Not sure if it was a GPU-2-72 assignment. But I have not submitted any NF-PM1 result below these limits.

I see two possible explanations:
Either this is an assignment that prime95 automatically unreserved without me noticing it, and some "random" GIMPS user did the P-1, or it was a factor-found result during stage 1, and therefore did not have S2.

I usually assign enough memory to mprime/prime95; I already feel bad if I see an "E=6" instead of the usual "E=12".

Please let me know my bad one, I still have all logs. If I did it, then I'll find it.

[QUOTE=Bdot;289160]Not sure if it was a GPU-2-72 assignment.

Please let me know my bad one, I still have all logs. If I did it, then I'll find it.[/QUOTE]

Yes, 45952603 was a GPU72 assignment, which had already been TFed to 72.

Your "bad one" was 49652243,640000,640000, which has been TFed to 71.

I am confused by this. The "PFactor=N/A,1,2,[EXPONENT],-1,[TFLEVEL],2" line is suppost to make Prime95 choose optimal bounds, and the fact that five of you have had one (or two) such situations while the rest were "nominal" is strange.

In addition, based on the data from James' site, it appears only one of monst's machines is doing this.

[B][I][U]Edit[/U][/I][/B]: [B]WAIT[/B]!!! 49652243 was one of the ones which experienced the "reassignment" bug from the end of last year. The B1=B2 result was submitted to PrimeNet by monst. Possibly the other five were as well, although it's strange that PrimeNet didn't accept the better P-1 work.

Let me drill-down and report back. But if you (Bdot) could look at what your logs show for both examples, it would be useful as well.

Not enough memory for stage2?

-- Craig

[QUOTE=chalsall;289146]James, any idea of a Prime95/mprime (mis)configuration which would result in only stage 1 being done in this manner?[/quote]Not offhand, no. The only Prime95 configuration that should affect this would be amount of RAM allocated, to determine whether stage2 should be done, and with what bounds. But if it was doing stage1-only due to lack of RAM, it would pick much higher B1=B2: Normal P-1 would be B1 ~500,000 and B2 ~12,000,000; with B1=B2 it would be ~1,200,000.

There are, of course, a plenitude of ways to "misconfigure" the worktodo to make it behave that way; the most obvious of which is to specify explicit bounds with Pminus1= instead of the usual Pfactor= lines.

[QUOTE=chalsall;289146]Any suggestions on how we can avoid this in the future? Should I reissue for another P-1 run in such cases? In the case of a better run the second worker would get the credit on PrimeNet (and G72).[/QUOTE][QUOTE=chalsall;289163]49652243 was one of the ones which experienced the "reassignment" bug from the end of last year. The B1=B2 result was submitted to PrimeNet by monst. Possibly the other five were as well, although it's strange that PrimeNet didn't accept the better P-1 work.[/QUOTE]Note that PrimeNet is a little weird in that it doesn't consider a subsequent P-1 run "better" unless B1.new > B1.old.

So, for example, if it (*M50M, TF=70) was poorly done once, with B1=B2=500,000 (=[url=http://mersenne-aries.sili.net/prob.php?exponent=50000000&b1=500000&b2=500000&factorbits=70]2.88%[/url]) and then re-done later with B1=490,000; B2=11,500,000 (=[url=http://mersenne-aries.sili.net/prob.php?exponent=50000000&b1=490000&b2=11500000&factorbits=70]4.93%[/url]), PrimeNet will ignore the new result even though it's arguably a better P-1, it doesn't meet the definition of "better" = "bigger B1".

Partial (but not full) explination...
 

Hey all.

OK, this is a "mash-up" of a query from the GPU72 database interweaved with queries from PrimeNet:

[CODE]49652243 - 2^71
B1=775000 by "ANONYMOUS" on 2012-02-09
+---------------------+----------+---------------+
| Assigned | FactFrom | DisplayName |
| 2011-11-25 14:05:56 | 71 | Bdot |
| 2011-12-31 21:13:18 | 71 | monst |

56161373 - 2^71
B1=775000 by "ANONYMOUS" on 2012-02-09
| 2012-01-27 01:34:21 | 71 | 1997rj7 |

49152443 - 2^72
B1=415000, B2=7573750 by "kurly" on 2011-11-24
B1=775000 by "ANONYMOUS" on 2011-12-17
| 2011-11-23 16:18:51 | 74 | kurly |

45571601 - 2^72
B1=510000 by "Stef42" on 2011-12-13
| 2011-12-12 21:54:10 | 72 | Stef42 |

49232621 - 2^72
B1=560000 by "Jerry Hallett" on 2012-01-04
| 2012-01-01 14:46:15 | 72 | Jerry Hallett |

49235027 - 2^72
B1=560000 by "Jerry Hallett" on 2012-01-04
| 2011-12-31 23:52:46 | 72 | Jerry Hallett |
[/CODE]

So, only Bdot's candidate experienced the reassignment bug. 1997rj7's result doesn't show up, while kurly's does. And, strangely, for kurly's [URL="http://www.mersenne.org/report_exponent/?exp_lo=49152443"]49152443[/URL] PrimeNet reports that the "Stage 1 only" effort was "better".

Lastly, for Stef42 and Jerry the "Stage 1 only" was what they actually did.

Any theories anyone?

One explination based on kurly's result is that 1997rj7's result was submitted after ANONYMOUS', and PrimeNet rejected it.

But we still have a puzzle as to why (at least) Stef42 and Jerry's machines (Bdot and 1997rj7's might have as well) did these unusual runs.... :sad:

I'll look up the results when I get home in a bit to see if I can track it down.

[QUOTE=James Heinrich;289168]

Note that PrimeNet is a little weird in that it doesn't consider a subsequent P-1 run "better" unless B1.new > B1.old.

So, for example, if it (*M50M, TF=70) was poorly done once, with B1=B2=500,000 (=[url=http://mersenne-aries.sili.net/prob.php?exponent=50000000&b1=500000&b2=500000&factorbits=70]2.88%[/url]) and then re-done later with B1=490,000; B2=11,500,000 (=[url=http://mersenne-aries.sili.net/prob.php?exponent=50000000&b1=490000&b2=11500000&factorbits=70]4.93%[/url]), PrimeNet will ignore the new result even though it's arguably a better P-1, it doesn't meet the definition of "better" = "bigger B1".[/QUOTE]
Is that something you can change while modifying the TF result parser?

In case it wasn't clear, I'm kurly. If I can be of any assistance in tracking this down, let me know. But it looks like the problem occurred after I turned in my results.

I like the 'top 100 factors found' list, I noticed I have a bunch of them. :smile:

[QUOTE=Dubslow;289173]Is that something you can change while modifying the TF result parser?[/QUOTE]It's certainly something I'll look at. To me, factor probability is a more sensible measure of "better" than simple B1.