Stuck available first-time exponents?

GP2 · 2003-10-13, 01:37

As of Oct 13 01:00 UTC the summary.txt file (displayed within http://www.mersenne.org/primenet/ ) shows:

Code:

    Exponent Range       Trial Factoring       Lucas-Lehmer      Double Checking
                        Avail   Out Factd   Avail   Out  Done   Avail   Out  Done
 --------------------   -----=-----=-----   -----=-----=-----   -----=-----=-----
  16500000   16599999                           1   137    40       1    39     4

  19500000   19599999                   9       2   981   355       1
  19600000   19699999                  16          1133   312             2     1
  19700000   19799999             1     7      20  1073   329                   1
  19800000   19899999             1    13      28  1080   383             1
  19900000   19999999                  14       3  1152   285       1     1     1
 
  20000000   20099999             1     6       6  1189   293             3
  20100000   20199999            66     4       2   702   263
  20200000   20299999                   8      13  1568   588
  20300000   20399999             7    24          1605   615
  20400000   20499999             5    39       7  1719   445
  20500000   20599999            19    33      16  1930   260
  20600000   20699999            25    33      14  2160    95
  20700000   20799999            24    23     364  1856     7
  20800000   20899999            43          2296     2
  20900000   20999999            74     1    2218

Thus there are apparently available first-time LL exponents at 16.5M, 19.5M, 19.7M, etc.

However, first-time LL assignments are being handed out in the 20M range.

One hour earlier at 0:00 UTC, the only difference in the "available column" was 18 at 20.1M and 16 at 20.2M, rather than 2 and 13 respectively as shown above.

In other words, the "available" exponents at 16.5M, 19.xM are apparently not being handed out, but are "stuck" as being available. I'm not sure how long that situation might have persisted.

I don't know which specific exponents those might be, since there's no way to get a list of "available" exponents from the server.

dswanson · 2003-10-13, 01:55

Actually, there is a brute-force way. Queue up in your worktodo all primes in the range of interest. Then contact the server to send expected completion dates. All unassigned exponents available on the server (including the stuck one) will be assigned to you; all others will report an error message. With a little extra work you could first weed out all values contained in status.txt and lucas_v.txt before contacting the server. You also need to set MaxExponents and UnreserveDays large in prime.ini to make this work.

I've used this method to pick up unassigned doublechecks in ranges outside of those being assigned by Primenet. I've never actually tried it on a "stuck" exponent, but I see no reason why it wouldn't work.

GP2 · 2003-10-13, 04:05

Quote:

Originally posted by dswanson
Actually, there is a brute-force way. Queue up in your worktodo all primes in the range of interest. Then contact the server to send expected completion dates. All unassigned exponents available on the server (including the stuck one) will be assigned to you; all others will report an error message.

But this only works for a certain range doesn't it? For instance, this will work for grabbing double-check exponents less than about 11M, but if you go higher than that the server will currently refuse to assign it to you, no? This is according to one of your earlier messages.

Quote:

I've used this method to pick up unassigned doublechecks in ranges outside of those being assigned by Primenet. I've never actually tried it on a "stuck" exponent, but I see no reason why it wouldn't work.

Well I'm not actually interested in grabbing those "stuck" exponents (or perhaps it's just a glitch in the summary.txt report and they don't even exist), just wanted to signal a possible server issue.

On the other hand I'm extremely interested in picking up specific exponents for doublechecking for purposes of detecting errorprone machines...

garo · 2003-10-13, 05:17

This is a known problem with the Primenet server. This usually happens when a result was returned before the exponent was factored fully. i.e. when someone disregarded specific instructions in undoc.txt and used the FactorOverride feature with Primenet.

You will find many more exponents in this category in the 21M range. There isn't really a way to free them unless you reserve them under your name and then unreserve them.

PS: There may be other causes for exponents to get stuck as well!

markr · 2003-10-13, 05:28

Quote:

Well I'm not actually interested in grabbing those "stuck" exponents (or perhaps it's just a glitch in the summary.txt report and they don't even exist), just wanted to signal a possible server issue.

They apparently exist... here are a couple threads from the Server forum: Stuck factoring assignments and DC's

[edit: I was too slow; garo was quicker!]

GP2 · 2003-10-13, 06:45

Thanks to everyone who replied, and especially to markr for the links to older threads.

I was surprised to find out from this thread that the 1 stuck exponent from 16.5M and the 2 stuck exponents from 19.5M have been stuck since at least June.

I think I figured out their identities:
16586939
19503313
19503349
which I successfully reserved and then released.

If these are now unstuck and get assigned, I'll unstick the rest.

Basically, a few days ago by coincidence I looked for all exponents that have no result returned (either a factor or at least one LL test) and are not currently assigned or cleared in Primenet, or in the list of manual test ranges that George provided to me.

That left a few exponents unaccounted for. I e-mailed George about this a few days ago wondering why those exponents were unassigned. But now putting 2 and 2 together, there's a fairly close correspondence. It's not an exact correspondence though: I see 3 untested/unassigned exponents in the 17M range but there are no "stuck available" exponents in that range.

GP2 · 2003-10-13, 07:20

OK, that seemed to work.

There is no longer a stuck exponent in the 16.5M range, so 16586939 must have been it. That exponent has now been automatically assigned to user "kaysel".

I guess there's no objections to unsticking the others? The exponents I'm looking at are all filtered against status.txt and therefore not currently assigned.

GP2 · 2003-10-13, 16:14

Quote:

Originally posted by GP2
I see 3 untested/unassigned exponents in the 17M range but there are no "stuck available" exponents in that range.

OK, never mind. Those are long-running factoring assignments... I inadvertently only filtered against LL-testing assignments.

Code:

17477531, F,59,10,774.0,-6.3,37.7,13-Sep-03 16:21,29-Aug-01 23:25,lozcs,Emily
17518421, F,59,12,768.5,6.5,60.5,06-Oct-03 11:23,04-Sep-01 11:40,mum,drm-Buzi-1
17883403, F,59,1,738.6,416.3,48.3,03-Sep-03 08:31,04-Oct-01 10:30,cardenas,topo14

These have been factoring more than two years.

dswanson · 2003-10-13, 18:18

Quote:

Originally posted by GP2
But this only works for a certain range doesn't it? For instance, this will work for grabbing double-check exponents less than about 11M, but if you go higher than that the server will currently refuse to assign it to you, no? This is according to one of your earlier messages.

It only works for exponent that have been released to Primenet for assignment. By definition, "stuck" exponents meet this criterion. The exponents cited in my earlier message had not been released for assignment, so it was impossible for me to pick them up.

But you seem to have found another way to solve the problem.

GP2 · 2003-10-14, 15:23

Quote:

Originally posted by dswanson
But you seem to have found another way to solve the problem.

Yes, I was able to pinpoint all the stuck first-time LL exponents and some of the factoring ones. For factoring there are still 2 at 22.5M and 3 at 22.8M whose identities I'm not sure of, but the next weekly edition of the nofactor file might clarify this.

Old man PrimeNet · 2003-12-04, 07:23

PrimeNet's daily self-maintenence system formerly released these exponents. Looks like it got turned off and left off. I will switch it back on soon.

The reason these appear 'stuck' is tied to Prime95/NTPrime <= v16, of which I recently saw several still running. I believe they are capable mostly of factoring now, which accounts for why mostly exponents having states 0x3 (assign to factor and/or LL), 0x1 (assign to factor), and 0x7 (assign to factor and/or dcheck-LL) get 'stuck'.

Note that unsuccessfully factoring a state 0x3 or 0x7 exponent should update the 'no factor thru N bits' value, and re-release the exponent for further testing.

There are two kinds of assignment result messages sent to the server - one to tell PrimeNet it's done with the work, the other to log a (digitally signed when valid but) otherwise arbitrary results.txt message for George's analysis. These older clients sent these messages in reverse order, log message first, then - and I'm not sure if I'm recalling this right - sometimes they would NOT send the 'assignment done' afterward.

Unfortunately, some folks then loaded up their results.txt files with bogus results so they'd get sent to the server to rack up false credit, a problem that also happened through the manual testing/sneakernetting web forms. Consequently, PrimeNet does not credit sneakernet work, nor results.txt log data.

As a result of seeing the log message first, PrimeNet knew the outcome of the test but would not know if the 'assignment done' was coming or not. So it flags the exponent as indeterminantly credited (and ergo unavailable for assignment), until either the 'assignment done' transaction followed nominally moments later, or the maintenance system rolled back the indeterminancy flag. Later versions > v16 worked fine, providing unambiguous crediting decisions.

So in summary, these 'stuck' exponents are the result of the combination of:
(a) v16 clients performing factoring work that fails to find a factor, and
(b) a disabled server daily self-maintenance system step.

I found the indeterminancy flag rollback procedure and ran it once just now. I next need to get it back into the daily maintenance queue.

2003-10-13, 01:37	#1
GP2 Sep 2003 101000011001₂ Posts	Stuck available first-time exponents? As of Oct 13 01:00 UTC the summary.txt file (displayed within http://www.mersenne.org/primenet/ ) shows: Code: Exponent Range Trial Factoring Lucas-Lehmer Double Checking Avail Out Factd Avail Out Done Avail Out Done -------------------- -----=-----=----- -----=-----=----- -----=-----=----- 16500000 16599999 1 137 40 1 39 4 19500000 19599999 9 2 981 355 1 19600000 19699999 16 1133 312 2 1 19700000 19799999 1 7 20 1073 329 1 19800000 19899999 1 13 28 1080 383 1 19900000 19999999 14 3 1152 285 1 1 1 20000000 20099999 1 6 6 1189 293 3 20100000 20199999 66 4 2 702 263 20200000 20299999 8 13 1568 588 20300000 20399999 7 24 1605 615 20400000 20499999 5 39 7 1719 445 20500000 20599999 19 33 16 1930 260 20600000 20699999 25 33 14 2160 95 20700000 20799999 24 23 364 1856 7 20800000 20899999 43 2296 2 20900000 20999999 74 1 2218 Thus there are apparently available first-time LL exponents at 16.5M, 19.5M, 19.7M, etc. However, first-time LL assignments are being handed out in the 20M range. One hour earlier at 0:00 UTC, the only difference in the "available column" was 18 at 20.1M and 16 at 20.2M, rather than 2 and 13 respectively as shown above. In other words, the "available" exponents at 16.5M, 19.xM are apparently not being handed out, but are "stuck" as being available. I'm not sure how long that situation might have persisted. I don't know which specific exponents those might be, since there's no way to get a list of "available" exponents from the server. Last fiddled with by GP2 on 2003-10-13 at 01:41

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
first-time LL Manual under 78M, no exponents?	preda	Information & Answers	7	2017-05-01 10:39
Stuck curtisc exponents?	NBtarheel_33	PrimeNet	70	2012-08-07 11:06
Release more exponents for first-time testing?	GP2	Data	10	2004-01-02 04:17
107 stuck exponents at 20.8M as of Oct 24 2003	GP2	Data	1	2003-10-24 21:32
Transfering Exponents and CPU time.	jeff8765	Lounge	10	2003-08-13 09:14

2003-10-13, 01:55	#2
dswanson Aug 2002 2³×5² Posts	Actually, there is a brute-force way. Queue up in your worktodo all primes in the range of interest. Then contact the server to send expected completion dates. All unassigned exponents available on the server (including the stuck one) will be assigned to you; all others will report an error message. With a little extra work you could first weed out all values contained in status.txt and lucas_v.txt before contacting the server. You also need to set MaxExponents and UnreserveDays large in prime.ini to make this work. I've used this method to pick up unassigned doublechecks in ranges outside of those being assigned by Primenet. I've never actually tried it on a "stuck" exponent, but I see no reason why it wouldn't work.

2003-10-13, 05:17	#4
garo Aug 2002 Termonfeckin, IE 101011001100₂ Posts	This is a known problem with the Primenet server. This usually happens when a result was returned before the exponent was factored fully. i.e. when someone disregarded specific instructions in undoc.txt and used the FactorOverride feature with Primenet. You will find many more exponents in this category in the 21M range. There isn't really a way to free them unless you reserve them under your name and then unreserve them. PS: There may be other causes for exponents to get stuck as well!

2003-10-13, 06:45	#6
GP2 Sep 2003 5·11·47 Posts	Thanks to everyone who replied, and especially to markr for the links to older threads. I was surprised to find out from this thread that the 1 stuck exponent from 16.5M and the 2 stuck exponents from 19.5M have been stuck since at least June. I think I figured out their identities: 16586939 19503313 19503349 which I successfully reserved and then released. If these are now unstuck and get assigned, I'll unstick the rest. Basically, a few days ago by coincidence I looked for all exponents that have no result returned (either a factor or at least one LL test) and are not currently assigned or cleared in Primenet, or in the list of manual test ranges that George provided to me. That left a few exponents unaccounted for. I e-mailed George about this a few days ago wondering why those exponents were unassigned. But now putting 2 and 2 together, there's a fairly close correspondence. It's not an exact correspondence though: I see 3 untested/unassigned exponents in the 17M range but there are no "stuck available" exponents in that range.

2003-10-13, 07:20	#7
GP2 Sep 2003 A19₁₆ Posts	OK, that seemed to work. There is no longer a stuck exponent in the 16.5M range, so 16586939 must have been it. That exponent has now been automatically assigned to user "kaysel". I guess there's no objections to unsticking the others? The exponents I'm looking at are all filtered against status.txt and therefore not currently assigned.

2003-12-04, 07:23	#11
Old man PrimeNet Jan 2003 Altitude>12,500 MSL 101 Posts	PrimeNet's daily self-maintenence system formerly released these exponents. Looks like it got turned off and left off. I will switch it back on soon. The reason these appear 'stuck' is tied to Prime95/NTPrime <= v16, of which I recently saw several still running. I believe they are capable mostly of factoring now, which accounts for why mostly exponents having states 0x3 (assign to factor and/or LL), 0x1 (assign to factor), and 0x7 (assign to factor and/or dcheck-LL) get 'stuck'. Note that unsuccessfully factoring a state 0x3 or 0x7 exponent should update the 'no factor thru N bits' value, and re-release the exponent for further testing. There are two kinds of assignment result messages sent to the server - one to tell PrimeNet it's done with the work, the other to log a (digitally signed when valid but) otherwise arbitrary results.txt message for George's analysis. These older clients sent these messages in reverse order, log message first, then - and I'm not sure if I'm recalling this right - sometimes they would NOT send the 'assignment done' afterward. Unfortunately, some folks then loaded up their results.txt files with bogus results so they'd get sent to the server to rack up false credit, a problem that also happened through the manual testing/sneakernetting web forms. Consequently, PrimeNet does not credit sneakernet work, nor results.txt log data. As a result of seeing the log message first, PrimeNet knew the outcome of the test but would not know if the 'assignment done' was coming or not. So it flags the exponent as indeterminantly credited (and ergo unavailable for assignment), until either the 'assignment done' transaction followed nominally moments later, or the maintenance system rolled back the indeterminancy flag. Later versions > v16 worked fine, providing unambiguous crediting decisions. So in summary, these 'stuck' exponents are the result of the combination of: (a) v16 clients performing factoring work that fails to find a factor, and (b) a disabled server daily self-maintenance system step. I found the indeterminancy flag rollback procedure and ran it once just now. I next need to get it back into the daily maintenance queue.