mersenneforum.org Requesting First-time LL tests but getting TF
 Register FAQ Search Today's Posts Mark Forums Read

 2009-02-06, 15:20 #1 rx7350     Feb 2006 AR, US 24·32 Posts Requesting First-time LL tests but getting TF 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?
2009-02-06, 18:28   #2
mdettweiler
A Sunny Moo

Aug 2007
USA (GMT-5)

11000011010012 Posts

Quote:
 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?

2009-02-06, 18:34   #3
petrw1
1976 Toyota Corona years forever!

"Wayne"
Nov 2006

112518 Posts

Quote:
 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?

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/

2009-02-06, 20:10   #4

"Richard B. Woods"
Aug 2002
Wisconsin USA

170148 Posts

Quote:
 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.)

Last fiddled with by cheesehead on 2009-02-06 at 20:14

2009-02-06, 21:23   #5
Mr. P-1

Jun 2003

100100100012 Posts

Quote:
 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.

2009-02-06, 22:23   #6
S485122

"Jacob"
Sep 2006
Brussels, Belgium

2×32×97 Posts

Quote:
 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

 2009-02-09, 01:16 #7 rx7350     Feb 2006 AR, US 24·32 Posts 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. Last fiddled with by rx7350 on 2009-02-09 at 01:18
 2009-02-09, 01:22 #8 starrynte     Oct 2008 California 22×59 Posts make sure it's set to first-time tests on the primenet page too. (http://www.mersenne.org/cpus)
 2009-02-09, 01:28 #9 garo     Aug 2002 Termonfeckin, IE 276410 Posts 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.
2009-02-09, 06:14   #10

"Richard B. Woods"
Aug 2002
Wisconsin USA

22×3×641 Posts

Quote:
 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.

Code:
[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.

Code:
...
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

Code:
/* 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 */

Last fiddled with by cheesehead on 2009-02-09 at 06:26

 2009-02-09, 07:54 #11 S485122     "Jacob" Sep 2006 Brussels, Belgium 2·32·97 Posts 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 Last fiddled with by S485122 on 2009-02-09 at 07:59

 Similar Threads Thread Thread Starter Forum Replies Last Post danmur Information & Answers 6 2016-12-13 12:44 moebius Data 4 2010-03-03 02:01 ixfd64 Software 1 2006-04-24 00:04 garo Data 5 2005-02-02 10:50 Prime95 Data 43 2003-11-17 22:25

All times are UTC. The time now is 16:35.

Wed Oct 27 16:35:11 UTC 2021 up 96 days, 11:04, 0 users, load averages: 2.43, 1.89, 1.51