Strategic Double Clicking

[storm5510]

Originally Posted by Mark Rose

I know George was able to figure out which CPUs did previously poor TF, and we both redid the TF work from those CPUs and DC'ed work from those CPUs. As far as I know, the CPU that reported work isn't available through the XML, so it has to be someone on the inside who figures out what work should be redone.

Everyone here seems to write only about CPU's. What about GPU's? Is their software so non-trustworthy that no one uses it?

[Mark Rose]

Originally Posted by storm5510

Everyone here seems to write only about CPU's. What about GPU's? Is their software so non-trustworthy that no one uses it?

It's more a case that all GPU work gets lumped into "manual assignments" making it not possible to differentiate a user's individual GPUs.

[storm5510]

Originally Posted by Mark Rose

It's more a case that all GPU work gets lumped into "manual assignments" making it not possible to differentiate a user's individual GPUs.

About a minute after sending my last, I realized that CPU is a relative term applying to a complete system. Therefore, CPU and GPU would essentially be the same. Correct?

[Mark Rose]

Originally Posted by storm5510

About a minute after sending my last, I realized that CPU is a relative term applying to a complete system. Therefore, CPU and GPU would essentially be the same. Correct?

No. When using Prime95/mprime, the system recognizes individual instances of Prime95/mprime. All other work is lumped together under "manual".

[GP2]

M81857519 and M81857537 should be marked suspect, or whatever the procedure was with those bogus Xolotl results. Shift counts are zero, I wonder what produced those bogus FFFFFFFF800000 residues.

Other results by this user/computer show normal-looking residues (for instance M80331397), but all are unverified.

[ixfd64]

I just found another factor missed by a previous P-1 run: https://mersenne.org/m47626037

[ATH]

Originally Posted by ixfd64

I just found another factor missed by a previous P-1 run: https://mersenne.org/m47626037

Back in 2009 maybe Stage2 was not run at all or only with low B2 like 10*B1 or 20*B1 instead of 100*B1. This factor would need B2>=48M.

[S485122]

Originally Posted by ixfd64

I just found another factor missed by a previous P-1 run: https://mersenne.org/m47626037

Originally Posted by ATH

Back in 2009 maybe Stage2 was not run at all or only with low B2 like 10*B1 or 20*B1 instead of 100*B1. This factor would need B2>=48M.

537933081092334292774343680 = 2^10 * 5 * 17 * 29 * 157 * 167 * 1181 * 144511 * 47626037 so B1 at 145000 would have been enough.
In 2009 P-1 was done with B1=745000 and found nothing : definitely a wrong result.

Jacob

[VictordeHolland]

Originally Posted by S485122

537933081092334292774343680 = 2^10 * 5 * 17 * 29 * 157 * 167 * 1181 * 144511 * 47626037 so B1 at 145000 would have been enough.

So it needs ~ B1=145 000 and B2=48 000 000

[ATH]

Originally Posted by S485122

537933081092334292774343680 = 2^10 * 5 * 17 * 29 * 157 * 167 * 1181 * 144511 * 47626037 so B1 at 145000 would have been enough.
In 2009 P-1 was done with B1=745000 and found nothing : definitely a wrong result.
Jacob

We do not know that since we cannot see the B2 value. If B2 was the standard 100*B1 (B2=74.5M) then yes it missed the factor, but perhaps due to low memory assigned to Prime95/mprime B2 was lower than that.

[GP2]

Originally Posted by VictordeHolland

So it needs ~ B1=145 000 and B2=48 000 000

Originally Posted by ATH

We do not know that since we cannot see the B2 value. If B2 was the standard 100*B1 (B2=74.5M) then yes it missed the factor, but perhaps due to low memory assigned to Prime95/mprime B2 was lower than that.

No, the 47626037 is the exponent itself. It's the "p" in 2kp + 1

See the mersenne.ca page, the factor should have been found in stage 1 with B1=144511 or higher. The B2 would only be relevant for stage 2.