Quick Question about assignments

[davieddy]

Originally Posted by Chuck

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

Chuck

I find this a superbly useful presentation of the state of play.

If you are wondering howcome a 46M exponent got TFed to 75 bits,
it was mine, and Eric Christenson saw fit to go that high.

I can't understand why it wasn't a prime

David

[davieddy]

Originally Posted by Prime95

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

Vacation?

David

[Dubslow]

Originally Posted by davieddy

I find this a superbly useful presentation of the state of play.
David

I think that's where a GPU-TF option becomes better than just raising the PrimeNet limits on the wavefront. Any expired LL's can be fed to the GPU-TF pool for, say, a month, before either getting TF'ed or dumped back to the pool. In other words, automate via a PrimeNet GPU-TF option what Mr. P-1 is doing.

[Christenson]

Originally Posted by Chuck

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

Chuck

Nope, I've been manually adjusting limits downward, usually to 70 bits....but the first two batches from Mr P-1 all asked for 72 bits, and a fair part of those batches indeed got 72 bits. Davieddy's get more, because I only do one of his every month or so, so that gets special handling.

Mr P-1:
No more factors found from batch #1.
Batch #2, still working on GTX480, and still doing those you said you wanted to run P-1 on, which I left to 72 bits. Some turned in. But the great mass is just about to be laid into, but not to 72 bits.

GTX440 is doing the small favor for P95, and then continuing on ckdo's stuff. Let's just call it "no assignment left behind".

Chuck:
A list of what I've been up to from Mr P-1 is in your PM. Let me know if there's any interference; duplicating effort is *not* what we want to do.

[Uncwilly]

Originally Posted by davieddy

Vacation?

[Wizzard]

Originally Posted by Dubslow

What's your hardware? How much RAM?

Intel Core 2 T5600, 1.83 GHz, 2 GB RAM. I had set 768 MB, I got another ECM assignment. Now I have set memory to 1024 MB, I got another ECM.

[Wizzard]

Originally Posted by Mr. P-1

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.

No effect. I tried MaxHighMemWorkers=1, restarted, MaxHighMemWorkers=2, restarted, memory is set to 1024, I still get ECM after manual communication.

[davieddy]

Originally Posted by Christenson

Davieddy's get more, because I only do one of his every month or so, so that gets special handling.
...
*not*

Careful with that axe Eugene. You know my penchant for
double entendres.

Sometimes my poor eyesight is to blame for mistaking
a double inverted comma (") for an asterisk (*).
Is it an American trait to use the latter for this purpose,
or simply some keyboard difference?

David

[LaurV]

@wizzard

First go to worktodo.txt and delete all ecm assignments you may have from the past **(see edit below), if you did not do that already. There is a possibility you requested some work for many days long ago when you might had "ecm" set as prefered work type (or "whatever makes sense"), and your worktodo is stuffed with already-got exponents to ecm.

They should look like

ECM2=_long_hex_key_,1,2,6264527,-1,50000,5000000,150

Delete all of them, eventually un-reserving them first.

Then go to prime.txt and check what you really have as "WorkPreference=xxxx" parameter. Check also "Test/Worker Windows..." in P95 menu to ensure you have the right work type queued for EACH and EVERY worker.

What you describe is a bit fishy and does not happen for any of us.

----------
edit: **: regardless of the order they appear, P95 will execute first the assignment that takes less time, so if you have first line in worktodo a LL test and second line a TF or ECM, the TF or ECM will be executed first. The reason is that if a factor is found, the longer job (LL) may not need to be done anymore, so a lot of time is saved.

[Wizzard]

Well, I had WorkPreference=4. Then I changed it to 5, unreserved one ECM exponent, set it again to P-1, and after manual communication I was assigned another P-1 work, at last. It seems that it works ok for now. Thank you all very much :)

[Mr. P-1]

Originally Posted by Wizzard

No effect. I tried MaxHighMemWorkers=1, restarted, MaxHighMemWorkers=2, restarted, memory is set to 1024, I still get ECM after manual communication.

That tip wasn't intended to fix your wrong-assignment problem, but to make better use of your available memory when you have P-1s running on both cores.