Requesting First-time LL tests but getting TF

[rx7350]

I have 'all workers' set to get first-time LL tests, but I'm getting TF on worker 2. Worker 2 just finished a first-time LL test.

Any ideas?

[mdettweiler]

Originally Posted by rx7350

I have 'all workers' set to get first-time LL tests, but I'm getting TF on worker 2. Worker 2 just finished a first-time LL test.

Any ideas?

Possibly it got an LL test that wasn't completely pre-TF'ed?

[petrw1]

Originally Posted by rx7350

I have 'all workers' set to get first-time LL tests, but I'm getting TF on worker 2. Worker 2 just finished a first-time LL test.

Any ideas?

What are your computer specs?

If you look at this page you will see that there are "rules" regarding what specs you need to get certain assignments.

http://www.mersenne.org/thresholds/

[cheesehead]

Originally Posted by rx7350

I have 'all workers' set to get first-time LL tests, but I'm getting TF on worker 2. Worker 2 just finished a first-time LL test.

What is the keyword on the line in worktodo.txt?

If it's "Test=", then that implies finishing up TF and/or P-1 for that exponent before commencing the LL, so that's why you'd see it doing TF on that exponent before the LL (which is what mdettweiler was getting at).

If it's "Factor=", then that's a pure TF assignment, with no LL following the TF. (In that case, petrw1's response may apply.)

[Mr. P-1]

Originally Posted by mdettweiler

Possibly it got an LL test that wasn't completely pre-TF'ed?

V24 behaviour was that on receiving an LL assignment not completely factored, the program would complete the factoring before commencing the LL. Assuming this behaviour hasn't changed, (I don't know for certain, since I have never done this) then the OP should be able to check for this by inspecting his worktodo.txt file.

Another possibility is that he has allocated insufficient memory for the program to do four LLs at once.

[S485122]

Originally Posted by Mr. P-1

Another possibility is that he has allocated insufficient memory for the program to do four LLs at once.

Memory allocation is only pertinent to P-1 (and ECM ?) stage 2. All other type of work ignore the value of "Memory" in local.txt.

Jacob

[rx7350]

The pc is a Core2 Duo E6700 with 2 gig of memory, so certainly capable of doing any kind of test.

The memory allocation is 512Mb.

The keyword is FACTOR, and there are nine assignments for worker 2 queued up even though I have it set to 'queue up 1 day of work' .

The pc is running PRIME95 version 25.7 build 3 .

This pc (RMCpc7) has been running 1st-time LL tests for over 2 years. Worker 1 is appears to be unaffected.

I have 'all workers' set for 'first time tests'. Looking at just worker 2 shows it to be set for 'first time tests' .

I did mistakenly switch it to TF about 3 weeks ago briefly, but switched it back when I realized I made a mistake. No TF assignments were received while it was briefly set to TF.

[starrynte]

make sure it's set to first-time tests on the primenet page too. (http://www.mersenne.org/cpus)

[garo]

We have a winner!

I had the same problem and checked my cpu properties page after reading starrynte's post and saw that one of the two cores was set to receive TFs. The change back to LL did not stick for some reason.

[cheesehead]

Originally Posted by garo

I had the same problem and checked my cpu properties page after reading starrynte's post and saw that one of the two cores was set to receive TFs. The change back to LL did not stick for some reason.

AHA! Maybe what happened in my case may be useful.

I'd previously noted that there are (at least) two different ways of specifying work type preferences in the .txt files. (It didn't occur to me to ask about them at the time.) The differences between them may explain how there can be a discrepancy between prime95 and PrimeNet settings!

In prime.txt, I have a WorkPreference=n line under each of the [Worker #k] headings.

[Worker #1]
WorkPreference=101

[Worker #2]
WorkPreference=4

In local.txt, there are 10 SrvrPxn lines above the [Worker #k] headings. SrvrPO1= appears to be the one for work type preference. Several days ago, when I experienced a discrepancy between prime95 and PrimeNet settings for work type preference, I found that the SrvrPO1= setting in local.txt was not the same as either of the WorkPreference settings in prime.txt.

So I deleted the SrvrPO1= line in local.txt that was above the [Worker #k] headings, and added a SrvrPO1= line below of those headings, setting each one to match the same work type number as the corresponding WorkPreference= setting in prime.txt. Since then, I've had no trouble getting Primenet to assign my desired work type to each worker.

However, just now I noticed that in local.txt there has reappeared a SrvrPO1= line above the [Worker #k] headings (and the ones below each of those headings remain) ... but its work type number doesn't match either of the ones below it.

...
SrvrPO1=2
MaxHighMemWorkers=1

[Worker #1]
Affinity=0
SrvrPO1=101

[Worker #2]
Affinity=1
SrvrPO1=4

I suspect that development of prime95/PrimeNet code relating to these work-preference lines (in particular, their synchronization) is not quite complete.

- - -

In v25.8 source module primenet.h are the lines

/* This structure is passed for the ga - Get Assignment call */

/* Valid work_types returned by ga */
#define PRIMENET_WORK_TYPE_FACTOR    2
#define PRIMENET_WORK_TYPE_PMINUS1    3
#define PRIMENET_WORK_TYPE_PFACTOR    4
#define PRIMENET_WORK_TYPE_ECM        5
#define PRIMENET_WORK_TYPE_FIRST_LL    100
#define PRIMENET_WORK_TYPE_DBLCHK    101
#define PRIMENET_WORK_TYPE_PRP        150    /* Unimplmented */

[S485122]

Work preference can be adjusted from the server and from the workstation, for all workers and per individual worker. For instance on a quad core :

SrvrPO1= in the general section of local.txt is a default for all workers. One can also specify it for each worker and that results in a SrvrPO1 line in each worker section.
local.txt :
[Worker #1]
Affinity=0
SrvrPO1=101
[Worker #2]
Affinity=1
SrvrPO1=100
[Worker #3]
Affinity=2
SrvrPO1=2
[Worker #4]
Affinity=3
SrvrPO1=100

Then in prime.txt there are lines that seem redundant but reflect how the server understands the preferences :
[Worker #1]
WorkPreference=101
[Worker #2]
WorkPreference=100
[Worker #3]
WorkPreference=2
[Worker #4]
WorkPreference=100

If I understood things correctly, the resulting settings are recorded in prime.txt. First what is set on the server is evaluated, then what is set locally, recorded in local.txt and that takes take precedence, first the general preference, then the per worker preference. That last one supercedes the general preference. In the "Test / Worker Windows" menu you have a setting for "All Workers" and a setting per worker. On my computers, the setting for "All Workers" is "Mixed Settings", so I do not have a SrvrP01 line in the general section of local.txt only in each Worker section.

Jacob