332.2M - 333.9M (aka 100M digit range)

[CADavis]

starting again with 332216147 - 332217971, most are to 68 already, going to take the range to 72 first, then 72 - 74. the first few are assigned to LL testers already so should I bother with those at all? http://v5www.mersenne.org/report_exp...&B1=Get+status

[S485122]

Originally Posted by CADavis

the first few are assigned to LL testers already so should I bother with those at all? http://v5www.mersenne.org/report_exp...&B1=Get+status

I think that once an exponent is assigned by the V5 server none other than the assignee should touch it. Of course in the 100 000 000 digit primes range some of the assignees will skip trialfactoring in the misunderstanding that they will go quicker. I still think it is better to just wait until they drop out.

Jacob

[Uncwilly]

Originally Posted by S485122

I think that once an exponent is assigned by the V5 server none other than the assignee should touch it. Of course in the 100 000 000 digit primes range some of the assignees will skip trialfactoring in the misunderstanding that they will go quicker. I still think it is better to just wait until they drop out.

If they show no progress after the number has been assigned to them for 15-30, I think that it is likely that they have skipped the TF.

[S485122]

Originally Posted by Uncwilly

If they show no progress after the number has been assigned to them for 15-30, I think that it is likely that they have skipped the TF.

likely

You are not sure and thus may be poaching. There is no urgency to treat those numbers. Even if it might be fun to search for the work ;-)

Jacob

[cheesehead]

Originally Posted by Uncwilly

If they show no progress after the number has been assigned to them for 15-30, I think that it is likely that they have skipped the TF.

I'll echo Jacob (though more softly and verbosely).

When one tries to deduce what is going on in an assignee's system, one runs the risk of having one's invalid assumptions about what is and is not shown in the reports lead one to a false conclusion.

That was doubly true in my own case.

Several years ago, the nonstandard way in which I was processing my LL assignments may have made it appear to someone looking at PrimeNet reports that I would be "holding up" some milestones, but in fact I was careful not to do that.

Then, the way in which someone else reported LL results to PrimeNet for exponents that had been assigned to me made it appear to me that the person was deliberately poaching my assignments. However, after I recently established communication with that person, he emphatically assured me that he did nothing of the sort, and had tested only exponents that had been properly assigned to him. That made me realize that I had not previously considered the possibility that all the evidence I had could be explained by some flaw in the assignment system rather than by poaching.

So, please don't do anything on exponents that are assigned to someone else. There are an infinity of Mersenne numbers with prime exponents, enough for everyone to work on exclusively with plenty left over.

[Uncwilly]

I have taken the advice of others to heart. I now grab the factor level report, make the worktodo.add, let Prime95 register assignments, then cull the N/A's.

Here is a progress status report for the range from 332192831 to 332259937

Date					12/20/2008
Average bit depth for first 100 expos	72.17
Average bit depth for first 1000 expos	69.23
100th active expo (no factor found)	332197793
1000th active expo (no factor found)	332240201
Unitless total effort number		1556864
Number of first 100 exos to 2^71	72
Number of first 1000 exos to 2^70	370

Bit	# to bit level or higher  
65	1482  <-all left in range
66	1234
67	1233
68	710
69	500
70	370
71	219
72	187
73	119
74	83
75	43
76	1
77	1

[S485122]

Exponent Range    Composite  Unproven  Assigned       Available			
Start      Count  F          NO-LL     TF   P-1  LL   TF
332000000  51080  27401      23679     648  1    653  22398

This shows that 21 assignments are overlapping (Unproven -Assigned-Available)

Jacob

[Uncwilly]

Originally Posted by S485122

This shows that 21 assignments are overlapping (Unproven -Assigned-Available)

I think that there are some expos that the server shows as assigned to me to LL, that are actually left over TF's. I want to get my hands on the machine and look at the worktodo.txt. I want to make sure that the entries are right, or fix them, or.... I haven't figured out how it happened. They may be part of the 21.

That and maybe the ones that got assigned LL, but TF killed, as reported previously.

[MercPrime]

Hey UncWilly, I'll join in when I'm done with my poking around below your range (321M 6-9 range).

[Uncwilly]

Here is a progress status report for the range from 332192831 to 332259937

Date					01/20/2008
Average bit depth for first 100 expos	72.69
Average bit depth for first 1000 expos	70.09
100th active expo (no factor found)	332197793
1000th active expo (no factor found)	332240677
Unitless total effort number		2309376 (accounts for only the 1st 1000 expos)
Number of first 100 exos to 2^71	96
Number of first 1000 exos to 2^70	394

Bit	# to bit level or higher  
67	1461  <-all left in range
68	1300
69	766
70	394
71	310
72	249
73	170
74	120
75	81
76	2
77	1

Some of my cores have been sidelined from this due to lack of access. They are still working for GIMPS. I have put one new core to working the range above this. It is a slower one and I will keep it at the lower bit depths. Once I get all the exponents in this range to 2^68, I will put that core onto the next higher area, bringing those expos up to 67 then 68. I plan on reviving the other cores and have then work the 69-72 area for this range.

[Uncwilly]

Originally Posted by Uncwilly

Here is a progress status report for the range from 332192831 to 332259937

I am now extending this particular range up to 332319979. The next stats (2/20) will reflect that. Anyone wanting to help can either work above me or take some of the higher bit levels.