Quick Question about assignments

[kladner]

Originally Posted by Wizzard

Yes, but the problem is, that I have set the options for All workers to P-1 factoring and Run on any CPU.

I'm sure that someone with more knowledge and experience than mine will weigh in on this.

But if I understand correctly, you already have some assignments. I'm not sure why you got the ECM with those settings, except perhaps Prime95 found the initial 300MB allocation too small for 2 P-1's. Given recent discussion, I would not have thought that this would be the case.

Whatever. Once a worker has assignments, it will keep working on them to completion unless you tell it to do otherwise. If you were doing ECM before, you may have some assignments in queue. Allowing more RAM under these conditions caused the P-1 worker to restart to take advantage of the larger amount.

Have a look at My Account>Assignments on the PrimeNet server to see what is going on. This will show if you have work which has not been started (in the Stage, % column). These can be unreserved without throwing away any work already done. When work in progress is completed, the worker should go to the chosen work type.

[Wizzard]

It is very interesting. I manually unassigned the ECM exponent works, and another ECM work was assigned again. I had to increase the memory to 600 MB and manually edit worktodo.txt to move some P-1 assignments from CPU1 to CPU2. Now it seems that it runs OK.

[Mr. P-1]

For various reasons, I take manual assignments, and manage my worktodo files myself, so I'm not sure what is going on with your ECM assignments. I'll have a play around later this evening when I have time.

For now, here's a tip: Put MaxHighMemWorkers=1 in local.txt. This means that one core will get all the memory all the time when doing stage 2, while the other will just move on to the next assignment. When the first core has finished doing stage 2, the second will go back to doing stage 2 on its first assignment. You need to exit the client in order for changes to local.txt to have effect.

Assuming that you have high memory available all the time, i.e., you don't have different daytime/nighttime settings, then over time you will accumulate a backlog of stage 2 work which takes rather longer than stage 1. So every now and again you will need to set MaxHighMemWorkers=2, to allow the backlog to clear.

[Dubslow]

Originally Posted by Wizzard

It is very interesting. I manually unassigned the ECM exponent works, and another ECM work was assigned again. I had to increase the memory to 600 MB and manually edit worktodo.txt to move some P-1 assignments from CPU1 to CPU2. Now it seems that it runs OK.

What's your hardware? How much RAM?

[Mr. P-1]

Originally Posted by Wizzard

It is very interesting. I manually unassigned the ECM exponent works, and another ECM work was assigned again. I had to increase the memory to 600 MB and manually edit worktodo.txt to move some P-1 assignments from CPU1 to CPU2. Now it seems that it runs OK.

I've played around a bit, and I've been unable to reproduce this behaviour. If I have 300MB available or more, I get P-1 assignments. If I have less, then I get doublechecks.

[Mr. P-1]

I've only just notice this post:

Originally Posted by Chuck

I have gotten a few that were already factored, but most are OK.

 
LL testing to "Mr. P-1" on 2011-09-25
no factor for M46203317 from 2^68 to 2^69 [mfaktc 0.17 barrett79_mul32] by "Eric Christenson" on 2011-10-12
no factor for M46203317 from 2^69 to 2^70 [mfaktc 0.17 barrett79_mul32] by "Eric Christenson" on 2011-10-15
no factor for M46203317 from 2^70 to 2^71 [mfaktc 0.17 barrett79_mul32] by "Eric Christenson" on 2011-10-20

Clearly I screwed up, and gave the same exponents to you and Christenson. Sorry about that. I hope there weren't too many.

[Mr. P-1]

Last Night's grab yielded

Below 50M:

12 exponents TFed to 68 (No P-1)
34 to 68 (P-1 done)
67 to 69 (No P-1)
133 to 69 (P-1 done)

50M and above:

102 to 69 (No P-1)
328 to 69 (P-1 done)

After 7 Days I have the following assignments available:

33 exponents TFed to 68 (No P-1)
34 to 68 (P-1 done)
169 to 69 (No P-1)
775 to 69 (P-1)

Additionally 1252 assignments are allocated to various people. Many of these will have been done, but the assignee has not reported back to me.

I have not kept track of the number of completed assignments returned to the server, though I would imagine that they run to three digits.

[davieddy]

Of course "breadth first" is best for the urgent retired expos.
But to focus the effort just ahead of the wavefront, it makes sense
to have more GPUs TFing fewer at a time to the sensible/feasible level
(72 ATM) in one go.
I note with dismay that primenet is dishing out 62M for TF,
rather than taking 55M to 72 bits.

David

[Chuck]

Originally Posted by Mr. P-1

I've only just notice this post:

Clearly I screwed up, and gave the same exponents to you and Christenson. Sorry about that. I hope there weren't too many.

None of the ones I received are scheduled for TF to 71; did Eric manually up the limits on his?

Chuck

[Prime95]

Originally Posted by davieddy

I note with dismay that primenet is dishing out 62M for TF,
rather than taking 55M to 72 bits.

When I get home this weekend I can work on this. My VPN connection to home isn't working.

[Dubslow]

Originally Posted by davieddy

Of course "breadth first" is best for the urgent retired expos.
But to focus the effort just ahead of the wavefront, it makes sense
to have more GPUs TFing fewer at a time to the sensible/feasible level
(72 ATM) in one go.
I note with dismay that primenet is dishing out 62M for TF,
rather than taking 55M to 72 bits.

David

I mostly agree. Getting some sort of GPU-TF assignment option is becoming more and more imperative, getting lower exponents to higher limits. I think that's probably the main reason why we're getting higher exponents and lower limits, because PrimeNet wants to make sure no CPU is being used inefficiently.

Edit: Ah, the joys of multiple posts being written simultaneously. It seems I've been preempted by George agreeing to do exactly this (okay maybe not exactly, but close enough).