[QUOTE=Mr. P-1;275449]I use TightVNC to do, I guess, the same job. I've never tried to cut@paste through it though, instead I pass data via a share on the "remote" machine I have mounted locally. I put "remote" in quotes, because it's physically right next to my main box, and connected via the LAN. Couldn't you do something similar with a genuinely remote system using VPN?[/QUOTE]

I don't have to use it very often. I'm not smart enough to get involved with anything more complicated.

GPU cycles available
 

I am running a Gtx 460, at a 15% OC: 776MHz. I can handle two PF's in mfaktc. Currently finishing up Primenet assignments in the 59M range, taking them from 69-72. Timings are:[INDENT]69-70 ~35-40min
70-71 ~1h 15m
71-72 ~2h 30m
[/INDENT]I would be glad to take up any more productive assignments which a more knowledgeable person would like to throw my way.

Those timings won't be accurate, because 45-50M exponents have 59/50-59/45 more possible factors to test.

[QUOTE=Dubslow;275619]Those timings won't be accurate, because 45-50M exponents have 59/50-59/45 more possible factors to test.[/QUOTE]

Those are the only references I have at the moment. But the offer of whatever GPU power they represent is open.

EDIT: But I'll happily keep knocking off PrimeNet assignments.

[QUOTE=Dubslow;275619]Those timings won't be accurate, because 45-50M exponents have 59/50-59/45 more possible factors to test.[/QUOTE]

Currently I'm collecting assignments at the 52M range and below which are TFed to 69 and below, I also keep any 53Ms and above TFed to 69 and below that I see, however there are very few, so I am not exhaustively searching these ranges.

Based upon the analysis I gave in [url=http://www.mersenneforum.org/showpost.php?p=275437&postcount=94]post #94[/url] in this thread, The priority for TFing these assignments should be.

1. 68 to 69 before 69 to 70
2. High exponents before low exponents (with the ranges currently being LLed of course).
3. Not P-1ed before P-1ed.

[QUOTE=kladner;275617]I am running a Gtx 460, at a 15% OC: 776MHz. I can handle two PF's in mfaktc. Currently finishing up Primenet assignments in the 59M range, taking them from 69-72. Timings are:[INDENT]69-70 ~35-40min
70-71 ~1h 15m
71-72 ~2h 30m
[/INDENT]I would be glad to take up any more productive assignments which a more knowledgeable person would like to throw my way.[/QUOTE]

I should very much like to take you up on your offer. Expect a PM shortly. Also, Thanks for the timings.

Sometimes I get one already TFd
 

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

[CODE]
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
[/CODE]

AND I am finding a few factors:

[CODE]
Processing result: M45999487 has a factor: 420481474810097427217
[/CODE]

[QUOTE=Mr. P-1;275672]I should very much like to take you up on your offer. Expect a PM shortly. Also, Thanks for the timings.[/QUOTE]

Thanks and you're welcome. One more timing:

68-69 = ~20min (GTX 460 @ 776MHz) Time/class: a bit over 1.3s, most of the time. There are scattered 1.4-1.5's.

EDIT: .....running in Win7-64, as are the timings given above. 32 bit XP is very roughly 10% slower.

Days 5 and 6 stats
 

The fifth day's grab yielded

Below 50M:

39 exponents TFed to 68 (No P-1)
28 to 68 (P-1 done)
49 to 69 (No P-1)
64 to 69 (P-1 done)

50M and above:

66 to 69 (No P-1)
170 to 69 (P-1 done)


Last night's grab yielded

Below 50M:

32 exponents TFed to 68 (No P-1)
67 to 68 (P-1 done)
68 to 69 (No P-1)
140 to 69 (P-1 done)

50M and above:

196 to 69 (No P-1)
230 to 69 (P-1 done)

[QUOTE=Dubslow;275619]Those timings won't be accurate, because 45-50M exponents have 59/50-59/45 more possible factors to test.[/QUOTE]
[B]WTF [/B]are you trying to say?

[QUOTE=davieddy;275678][B]WTF [/B]are you trying to say?[/QUOTE]

I'm saying that TF at 59M takes less time than at 45M.

Mr. P-1, I can take about 50 more assignments. The first batch is almost done.

48M from 69-70 took almost exactly 30 minutes, around 30:07 plus or minus a few seconds.

[QUOTE=davieddy;275678][B]WTF [/B]are you trying to say?[/QUOTE]

He's trying to say he's been reading up on the math, and there are fewer potential factors (note: all of form 2kp+1, where p is your mersenne exponent) of 2^p-1 at, say, 69 bits, when p is 55M versus when it's 45M, and this affects his run-time.

AND he's doing exactly what you complained about us not doing, which is ensuring better TF levels for all LL assignments!

Hello, I have one question. I am using manual assignments to [B]Trial factoring to low limits[/B] and I have set [B]Days of work to queue up[/B] to [B]5[/B], but the total amount of work last only for about one day. Then, when I am without internet connection, Prime95 stops working. It is not a bug in a program? I know, I may use another kind of work (for example normal Trial factoring), but I am just curious if this program behaviour is OK.

Another question. Is there some table or summary that shows which kind of work is the most cpu consuming and what is the least? I would like to see all the types of work and compare them (including P-1 factoring etc.)

Thank you very much.

I dunno about tables, but I can give a quick overview of each assignment. (For the record, any assignment will put full, 100% load on the cpu, but I'm assuming that's not what you meant.)

Trial factoring varies heavily depending on what bit levels you're doing it at. Low-limit assignments are very, very short, i.e. a few minutes, maybe 15 on an average processor. "Normal" trial factoring again depends on the factoring depth (each bit takes twice as long as the previous one) but typical assignments take from a quarter of a day to one or two days, depending on the assignment and cpu speed.

P-1 factoring is another way to find factors, and again, varies with circumstances. A typical assignment will take one or two days, or for a large assignment maybe three. The second stage will also use 500MB - 1GB of memory (RAM) or more if you let it.

LL testing is very, [I]very[/I] long. Current LL assignments take me a month, and I have Intel's fastest processor. On average they can be anywhere from a month to three or four or more, depending heavily on cpu speed.

All these time estimates assume you run P95 24 hours per day.

As for why it's not queuing 5 days of work, my guess (only a guess) would be that because each assignment is 15 minutes long, that even 1 day of work is ~100 assignments, and it's not getting more than some preset maximum. Guys, any other ideas?

Ok, I see, that TF to low limits is the fastest work. Also it seems that different CPUs get different TF limits in normal TF assignments according to that CPU speed.

LL testing, double checking and P-1 testing is very slow.

What about ECM of small Mersenne numbers and Fermat numbers?

About that queuing 5 DOW, it seems that the number of assignments per CPU is limited to 15.

[QUOTE=Wizzard;275780]Ok, I see, that TF to low limits is the fastest work. Also it seems that different CPUs get different TF limits in normal TF assignments according to that CPU speed.

LL testing, double checking and P-1 testing is very slow.

What about ECM of small Mersenne numbers and Fermat numbers?

About that queuing 5 DOW, it seems that the number of assignments per CPU is limited to 15.[/QUOTE]

ECM on small exponents may be somewhat between TF-low and TF.
ECM on Fermat numbers is between LL-D and LL.

Luigi

[QUOTE=Wizzard;275780]About that queuing 5 DOW, it seems that the number of assignments per CPU is limited to 15.[/QUOTE]

You can change this limit by putting

[code]MaxExponents=100[/code]

or whatever number you choose, into prime.txt. See undoc.txt for details.

^^ Thank you very much, gyus :tu:

[QUOTE=Dubslow;275779]P-1 factoring is another way to find factors, and again, varies with circumstances. A typical assignment will take one or two days, or for a large assignment maybe three. The second stage will also use 500MB - 1GB of memory (RAM) or more if you let it.[/QUOTE]

P-1 factoring is the worktype the project most needs currently. The minimum memory requirement to be given this type of work is 300MB and you can do a perfectly respectable job with that minimum. More is better, and the client will happily gobble up as much ram as you can throw at it. The returns from allowing more memory diminish rapidly and are really quite marginal after 1GB or so.

Trial factorisation is the least needed worktype, as far as CPUs are concern. GPUs leave CPUs in the dust, and have basically made them obsolete at this task.

Okay, I will consider running P-1 factoring.

You said, that GPUs can run Prime95 too or what? It means, I may run Prime95 at my graphics card? :)

[QUOTE=Wizzard;275793]Okay, I will consider running P-1 factoring.

You said, that GPUs can run Prime95 too or what? It means, I may run Prime95 at my graphics card? :)[/QUOTE]

GPUS cannot run Prime95. There are, however, other programs which use [i]some[/i] GPUs to do blisteringly fast TF and somewhat fast LL testing. These programs are not as mature as Prime95, and need more user intervention to keep things running.

Check out the [url=http://www.mersenneforum.org/forumdisplay.php?f=92]GPU computing forum[/url] for more information.

I set the memory usage to 300 MB and work type to P-1 factoring. First CPU core assigned P-1 testing, second core ECM testing. I tried to increase memory to 600 MB, but the same result, and all the memory was used to first core P-1 and that work was restarted.

Is it possible to run P-1 on both CPU cores?

[QUOTE=Wizzard;275803]I set the memory usage to 300 MB and work type to P-1 factoring. First CPU core assigned P-1 testing, second core ECM testing. I tried to increase memory to 600 MB, but the same result, and all the memory was used to first core P-1 and that work was restarted.

Is it possible to run P-1 on both CPU cores?[/QUOTE]

You can set the assignments individually by core. Go to the Test menu>Worker Windows. If you look at individual worker numbers in the first drop-down, you can then set work type and core affinity for each one.

[QUOTE=kladner;275809]You can set the assignments individually by core. Go to the Test menu>Worker Windows. If you look at individual worker numbers in the first drop-down, you can then set work type and core affinity for each one.[/QUOTE]

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

[QUOTE=Wizzard;275811]Yes, but the problem is, that I have set the options for [B]All workers[/B] to [B]P-1 factoring[/B] and [B]Run on any CPU[/B].[/QUOTE]

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.

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.

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.

[QUOTE=Wizzard;275815]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.[/QUOTE]

What's your hardware? How much RAM?

[QUOTE=Wizzard;275815]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.[/QUOTE]

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.

I've only just notice this post:

[QUOTE=Chuck;275674]I have gotten a few that were already factored, but most are OK.

[CODE]
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
[/CODE][/QUOTE]

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

Day 7 Stats
 

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.

Clarification of my "bit depth" philosophy
 

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

[QUOTE=Mr. P-1;275866]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.[/QUOTE]

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

Chuck

[QUOTE=davieddy;275879]
I note with dismay that primenet is dishing out 62M for TF,
rather than taking 55M to 72 bits.[/QUOTE]

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

[QUOTE=davieddy;275879]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[/QUOTE]

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

[QUOTE=Chuck;275884]None of the ones I received are scheduled for TF to 71; did Eric manually up the limits on his?

Chuck[/QUOTE]I find [URL="http://www.mersenne.info/trial_factored_tabular_data/2/40000000/"]this[/URL] 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:smile:

David

[QUOTE=Prime95;275889]When I get home this weekend I can work on this. My VPN connection to home isn't working.[/QUOTE]

Vacation?

David

[QUOTE=davieddy;275891]I find [URL="http://www.mersenne.info/trial_factored_tabular_data/2/40000000/"]this[/URL] a superbly useful presentation of the state of play.
David[/QUOTE]
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.

[QUOTE=Chuck;275884]None of the ones I received are scheduled for TF to 71; did Eric manually up the limits on his?

Chuck[/QUOTE]
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". :smile:

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.

[QUOTE=davieddy;275893]Vacation?[/QUOTE]:curtisc: :smile:

[QUOTE=Dubslow;275847]What's your hardware? How much RAM?[/QUOTE]

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.

[QUOTE=Mr. P-1;275824]

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.[/QUOTE]

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

[QUOTE=Christenson;275906] Davieddy's get more, because I only do one of his every month or so, so that gets special handling.
...
*not*[/QUOTE]
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

@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.

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

[QUOTE=Wizzard;275951]No effect. I tried MaxHighMemWorkers=1, restarted, MaxHighMemWorkers=2, restarted, memory is set to 1024, I still get ECM after manual communication.[/QUOTE]

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.

A productive TF overnight run
 

I had a productive session last night; found three factors.

[CODE]
46330591 F 2011-10-27 13:28 579283106400752148679
46234651 F 2011-10-27 13:28 532673574252176900863
45699749 F 2011-10-27 13:28 565866049829123082257
[/CODE]

Chuck

[QUOTE=davieddy;275955][SNIP] 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[/QUOTE]

I'm not sure about everyone's habits, but I frame words in asterisks as a form of emphasis, especially in environments which don't allow such niceties as Bold, Italic, or Underscore. That doesn't apply here, but habits take on lives of their own.

I use quotes to indicate a degree of disposession -- someone else's words, not to be taken as gospel from me....

[QUOTE=kladner;275987]I'm not sure about everyone's habits, but I frame words in asterisks as a form of emphasis, especially in environments which don't allow such niceties as Bold, Italic, or Underscore. That doesn't apply here, but habits take on lives of their own.[/QUOTE]

I generally use asterisks to express something that isn't meant to be thought of as spoken. Like,

"There's a giant bird come to kidnap us!"
*ducks* (-- get it?)
"Nevermind, we all ducked, it went right over us!"

Or

*smacks the Brit for being Brit*:smile::lol:

[QUOTE=LaurV;275956]
----------
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.[/QUOTE]
This is emphatically not true.

From undoc.txt: [CODE]The program used to do factoring and P-1 testing on exponents even if
they were not the first entry in worktodo.txt. The rationale was that
if the number had a factor, the server could be contacted and another
exponent reserved. This avoids the possible scenario where the LL test
for the first worktodo.txt line completes, a factor is quickly found for
the second line in worktodo.txt and the computer now sits idle until
the server can be contacted. This behavior was confusing, especially
to newcomers. To restore this old behavior add this line to prime.txt:
SequentialWorkToDo=0
One added benefit is time estimates in Test/Status will be more accurate
because we'll know no factors will be found and the LL test must be run.[/CODE] What you said about saving tests is correct, but Prime95 no longer works that way.

[QUOTE=LaurV;275956]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.[/QUOTE]

[QUOTE=Dubslow;276028]This is emphatically not true.[/QUOTE]

Nor was it ever true. prime95 would never prioritise, for example, the second of the following over the first, even if it would be quicker:

[code]Factor=exponent1,67,68
Factor=exponent1,66,67[/code]

The only thing it ever did, as explained in undoc.txt, is prioritise the factorisation stage(s) of Test and doublecheck assignments.

Erm, Mr. P-1, it seems I got my threads mixed up. Can you send me another 50-100 assignments? Probably closer to 100, I only have 25 in queue right now.

[QUOTE=Dubslow;276037]Erm, Mr. P-1, it seems I got my threads mixed up. Can you send me another 50-100 assignments? Probably closer to 100, I only have 25 in queue right now.[/QUOTE]

Check your mail.

Could everyone who has accepted assignments from me please send me your results files after you have submitted them to the server. It doesn't matter if they have other assignments mixed in with mine.

Thanks everyone for your help.

[QUOTE=Mr. P-1;276047]Could everyone who has accepted assignments from me please send me your results files after you have submitted them to the server. It doesn't matter if they have other assignments mixed in with mine.

Thanks everyone for your help.[/QUOTE]

Got it. Will do.

[QUOTE=Mr. P-1;276047]Could everyone who has accepted assignments from me please send me your results files after you have submitted them to the server. It doesn't matter if they have other assignments mixed in with mine.

Thanks everyone for your help.[/QUOTE]

I don't have them. But I can give you a list of factors found, if that's sufficient?

Sorry for another stupid question. What it the difference between [B]Smart assignment[/B] and [B]Run on any CPU[/B]?

[QUOTE=davieddy;276062]Admirable as your "grabbing" efforts are, it is a one-off exercize. Provided the new exponents dished out are optimally TFed (72) even the expiries will have no further need for TF. Maybe some P-1.[/QUOTE]

That is correct. If new exponents dished out are optimally TFed, then [i]eventually[/i] expiries will have no further need for TF. Just now, they do. Currently new exponents are TFed to 71. Over time, the number of expiries < 71 will diminish while the mini-project's capacity might increase. [i]Eventually[/i] we will be able to do all these expiries and then some. At this point we start impementing your proposal.

But [i]until then[/i], it is better that we catch the low TF expiries.

[QUOTE=Christenson;276058]Do you want factors, or the no factor found results, too?[/QUOTE]

It's actually the no factor found results I want. The factored assignments are nice to know about, but they will unreserve themselves.

[QUOTE=kladner;276061]EDIT: When I took up this task, Mr. P-1 said approximately, "You don't have to tell me about factors, but it's OK if you do."

I've settled on saving the contents of uploaded results.txt files in one file and shooting that off to Mr. P-1. No filtering. He can do as he wants with it. He already said that it doesn't have to be all his stuff, though that's all I have from mfaktc at the moment.

It's also really easy once the results have been uploaded. Ctl-A, Ctl-X, Ctl-S, (switch files) Ctl-V, Ctl-S. Maybe there's even a way to batch file that.[/QUOTE]

All rolled up together in one file is just fine. In fact, it's better for me.

I'm now tracking 19 batches given to 11 different volunteers. I've had to develop processes to manage this burgeoning workload on the hoof. What I'm looking for, is a way to minimise my own workload, minimise yours, and reduce the scope for screwup as much as possible. I can think of several ways to do this:

Option 1. I maintain a record of each batch I give you. When you've completed a batch, you tell me, identifying which batch by the ID I gave you. This is what I have been doing since a few days ago, until yesterday.

Pros: Fairly convenient for me.

Cons: "All I did was copy your assignments to my worktodo, then delete your email/PM. I don't know what assignment belongs to what batch, and in any case, you never did give me a batch ID"

Option 2: "Here are the assignment keys. Unreserve them all when you're done"

Pros: Really easy for me as I no longer have to track what I've given you.

Cons: "How do you unreserve assigments again? All I did was copy your assignments to my worktodo, then delete your email/PM. My worktodo still lists the uncompleted assignments but I no longer have a list of those I have completed."

Option 3: You send me back a list of completed assignments. I grep my tracking files for these assignments, unreserve them, then (using grep again) remove them.

Pros: Convenient for me

Cons: "All I did was copy your assignments to my worktodo, then delete your email/PM. My worktodo still lists the uncompleted assignments but I no longer have a list of those I have completed." Also there's the possibility of error. You may report as completed an assignment that you actually haven't.

Option 4: You send me your results files. I parse them for the exponents using a script, then proceed as in option 3.

Pros. Easy for me. Easy for you. Reduced scope for error.

Cons: None that I can think of.

[QUOTE=Dubslow;276069]I don't have them. But I can give you a list of factors found, if that's sufficient?[/QUOTE]

I don't need the factors found, though they're nice to know. But you're good anyway, you've already told me about some batches you've completed, which I'll unreserve shortly. Just let me have the results files moving forward. If any discrepancies emerge, I'll contact you.

One Con I know of for option 4: the 5000 character limit on PMs. But it's a zero; I keep my results files sort of permanently; the file is up to 200K or so, which is, compared to a drive with 100s of Gigabytes, pretty small....

[QUOTE=Mr. P-1;276097]At this point we start impementing your proposal.
[/QUOTE]

[URL="http://www.youtube.com/watch?v=W9nmfcRp6ZY"]Don't impement(sic) with my tutu[/URL]

David

It seems clear that this process needs to be implemented in the PrimeNet software. NOW. I'm sorry that I'm not smart enough to offer any assistance.

Why not have just one batch per volunteer to minimize confusion? When I finish, I email and say "I'm done, send more". Perhaps there will be a little dead processing time between batches but so be it.

[QUOTE=Mr. P-1;276099]I'm now tracking 19 batches given to 11 different volunteers. I've had to develop processes to manage this burgeoning workload on the hoof. What I'm looking for, is a way to minimise my own workload, minimise yours, and reduce the scope for screwup as much as possible. I can think of several ways to do this:[/QUOTE]

If it would help this sub-project, I'd be willing to invest a bit of time to modify my "MiniPrimeNet" code to facilitate this.

I'm thinking something along the lines of:

1. Mr. P-1 and anyone else collecting expired candidates uploads the exponents after getting them assigned as Anonymous.

2. "Workers" log into the server and ask for some number of assignments and what bit level they're going to work them up to.

3. The server watches these exponents (once a day or so, to not have too high an impact on the real PrimeNet server), and automatically unassigns them once it sees the pledged bit level has been achieved.

Would this be at all useful and desirable?

If so, if Mr. P-1 could PM me a sample set of exponents which the server would have to parse during step 1, I could probably get this implemented over the weekend.

It seems like it would be better to just use PrimeNet, but if George doesn't have the time, this is the next best option.

[QUOTE=chalsall;276113]
"Workers" log into the server and ask for some number of assignments and what bit level they're going to work them up to.
[/QUOTE]
Shirkers of the world unite.
What have we got to lose?

David

[QUOTE=Dubslow;276129]It seems like it would be better to just use PrimeNet, but if George doesn't have the time, this is the next best option.[/QUOTE]
It's not the time. It's the inclination.

Pottymouth

[QUOTE=Dubslow;276129]It seems like it would be better to just use PrimeNet, but if George doesn't have the time, this is the next best option.[/QUOTE]

Eventually all new test assignments and expiries will be already TFed to the optimum 72, and our project will come to an end, no change to Primenet needed. It's also worth noting that all our efforts are saving just a handful of LL tests per day. George's time is certainly better spent on implementing an AVX FFT.

[QUOTE=Dubslow;276129]It seems like it would be better to just use PrimeNet, but if George doesn't have the time, this is the next best option.[/QUOTE]

Of course -- if PrimeNet could do the work, that would be optimal.

Thinking a bit more about this...

1. With regards to my point 1 above, there's no reason my system couldn't do the reservations itself, in addition to or instead of human effort.

2. With regards to my point 3 above, if a worker only "pledged" to take an exponent up to, say, 70 but it was agreed that it would be better to not release exponents until they were up to, say, 71, the system could then reassign the exponent to another worker pledging to take it from 70 to 71 once the first worker had completed their work.

But an observation / question... Would this not result in the LL wave front temporarily being pushed ahead? Although, with a long-term net benefit to the GIMPS effort.

Thoughts?

I'd only invest the effort if everyone (including George) agrees it's a good idea.

[QUOTE=chalsall;276113]If it would help this sub-project, I'd be willing to invest a bit of time to modify my "MiniPrimeNet" code to facilitate this.

I'm thinking something along the lines of:

1. Mr. P-1 and anyone else collecting expired candidates uploads the exponents after getting them assigned as Anonymous.[/QUOTE]

Is there any reason MiniPrimeNet couldn't collect the expired candidates itself?

[QUOTE]2. "Workers" log into the server and ask for some number of assignments and what bit level they're going to work them up to.[/QUOTE]

Default to 70, with the option of going higher than 70, if the worker insists. We strongly want to encourage workers to do more assignments to 70, rather than fewer to higher levels. Over a period of months, we will need to raise that limit first to 71, and then, to davieddy's delight, to 72.

Also exponents already TFed to low levels (currently 68) should be prioritised over those TFed to high (currently 69). High exponents at the same TF level should be prioritised over low.

[QUOTE]3. The server watches these exponents (once a day or so, to not have too high an impact on the real PrimeNet server), and automatically unassigns them once it sees the pledged bit level has been achieved.[/QUOTE]

I presume you mean unreserve them on the real PrimeNet server, and not merely record them as unassign in its own internal database.

OK, but I'd also like it to keep hold of small exponents TFed to 70 (or whatever the current default is) and needing P-1, as I and perhaps others would want to take some of these on.

[QUOTE=Mr. P-1;276146]Is there any reason MiniPrimeNet couldn't collect the expired candidates itself?[/QUOTE]

Our messages crossed.

Yes, MiniPrimeNet could certainly collect the candidates. I already have code for that kind of work.

[QUOTE=Mr. P-1;276146]Default to 70, with the option of going higher than 70, if the worker insists. We strongly want to encourage workers to do more assignments to 70, rather than fewer to higher levels. Over a period of months, we will need to raise that limit first to 71, and then, to davieddy's delight, to 72.[/QUOTE]

Agreed. As davieddy said, "breadth first". But there should be some thought about how wide the "breadth" should be.

[QUOTE=Mr. P-1;276146]Also exponents already TFed to low levels (currently 68) should be prioritised over those TFed to high (currently 69). High exponents at the same TF level should be prioritised over low.[/QUOTE]

A simple "order by ..." clause in the SQL query.

[QUOTE=Mr. P-1;276146]I presume you mean unreserve them on the real PrimeNet server, and not merely record them as unassign in its own internal database.[/QUOTE]

Yes -- that's what I meant.

[QUOTE=Mr. P-1;276146]OK, but I'd also like it to keep hold of small exponents TFed to 70 (or whatever the current default is) and needing P-1, as I and perhaps others would want to take some of these on.[/QUOTE]

Three options here:

1. You keep to yourself and work those low exponents you yourself have reserved.

2. There be an option in MiniPrimeNet which says: "I claim ownership of this Exponent until I tell you otherwise.

3. A possible bonus option: MiniPrimeNet does not unreserved low exponents once the agreed upon TF level has been reached so that P-1 workers like you have an opportunity to claim and work them.

There would have to be a balance between the number of exponents reserved by this system vs. the amount of "fire power" available.

Further thoughts?

We crossposted. You've already addressed some of my earlier points.

[QUOTE=chalsall;276141]1. With regards to my point 1 above, there's no reason my system couldn't do the reservations itself, in addition to or instead of human effort.[/quote]

At the moment, I take all expiries less than 53M, filter out those TFed to 70 and higher (except for small P-1 ready exponents at 70 which I want to do myself), and unreserve these. The rest are added to my reserves.

The overwhelming majority of assignments I've seen over 53M are already TFed to 70 or higher.

[QUOTE]2. With regards to my point 3 above, if a worker only "pledged" to take an exponent up to, say, 70 but it was agreed that it would be better to not release exponents until they were up to, say, 71, the system could then reassign the exponent to another worker pledging to take it from 70 to 71 once the first worker had completed their work.[/QUOTE]

At the moment there are so few TFed to 68 that it's probably not worth even offering the option to just TF to 69. My guess is, that by the time we raise the limit from 70 to 71, there will be very few TFed to just 69.

[QUOTE]But an observation / question... Would this not result in the LL wave front temporarily being pushed ahead? Although, with a long-term net benefit to the GIMPS effort.[/QUOTE]

Yes it will. It already has, by a few thousand exponents. As you point out, this is temporary.

[QUOTE]I'd only invest the effort if everyone (including George) agrees it's a good idea.[/QUOTE]

Indeed. When I started, I only had three volunteers and a few hundred assignments. I didn't then think it necessary to contact him. Now it's burgeoned to a dozen volunteers and thousands of exponents. But he knows about it, and he hasn't objected.

I think chalsall's offer is generous and we should take it. I would much prefer a semi-automated system to messing around with PMs and emails.

You could easily code some logic into your mini-Primenet that would unreserve exponents after a certain dynamic bit-level which would be based on the rate at which work is being completed/P-1 status etc. etc. I will happily volunteer to be your first client.

[QUOTE=chalsall;276147]Our messages crossed.[/QUOTE]

Ping-pong!

[QUOTE]Three options here:

1. You keep to yourself and work those low exponents you yourself have reserved.

2. There be an option in MiniPrimeNet which says: "I claim ownership of this Exponent until I tell you otherwise.[/QUOTE]

Neither of these would work for me. I don't have a GPU and won't be taking any TF assignments.

[QUOTE]3. A possible bonus option: MiniPrimeNet does not unreserved low exponents once the agreed upon TF level has been reached so that P-1 workers like you have an opportunity to claim and work them.[/QUOTE]

Many of the assignments already have had P-1 done, but there may also be testers who would like small assignments TFed and P-1ed.

[QUOTE]There would have to be a balance between the number of exponents reserved by this system vs. the amount of "fire power" available.[/QUOTE]

Of course. At the moment the firepower has increased as such a rate that I don't feel that my reserves have become excessive, but I always assumed that I would probably have to start unreserving stuff eventually. When that happened, I was still intending to do a full grab every day. Then I would keep the highest priority assignments and drop the lowest.

[QUOTE=garo;276150]I think chalsall's offer is generous and we should take it. I would much prefer a semi-automated system to messing around with PMs and emails.[/QUOTE]

I agree. Of course, this will leave me [url=http://www.youtube.com/watch?v=XTe7M7gBgvs]completely redundant[/url].

[QUOTE=Mr. P-1;276156]I agree. Of course, this will leave me [url=http://www.youtube.com/watch?v=XTe7M7gBgvs]completely redundant[/url].[/QUOTE]

:smile: There is an old saying... Never send a human to do a machine's job...

Based on your and Garo's support, I'm beginning implementation.

[QUOTE=Mr. P-1;276139]Eventually all new test assignments and expiries will be already TFed to the optimum 72, and our project will come to an end, no change to Primenet needed. It's also worth noting that all our efforts are saving just a handful of LL tests per day. George's time is certainly better spent on implementing an AVX FFT.[/QUOTE]

Not just for this mini project, I meant a GPU-TF assignment option on the manual page, so that we can take lower exponents to a higher limit, beyond what CPU's should or can do. The risk with just upping bounds is that some CPU could easily get stuck with an assignment meant for a GPU. It just happens that such an option implemented now would automate this mini-project, as only a side effect, not primary cause.

[QUOTE=garo;276150]I think chalsall's offer is generous and we should take it. I would much prefer a semi-automated system to messing around with PMs and emails.[/QUOTE]
[QUOTE=chalsall;276163]:smile: There is an old saying... Never send a human to do a machine's job...

Based on your and Garo's support, I'm beginning implementation.[/QUOTE]
Standing on the side lines (I don't have a GPU), I think that your offer is dynamite. Go forth and prosper.:tu::bow:

Could this MiniPrimeNet offer to further factor at the DC level? I know I would use such a system.

At any rate, I think the Idea is awesome!

Man, I've had the crappiest luck on the 45M-50M ranges I've gotten from Mr. P-1. Just one fricken factor in at least 200 tested. Mr. P-1, do the PrimeNet changes obsolete your project? I tested it once with 5 assignments, and they were 56M from 70 to 71. If you have any, I could use another 50.

[QUOTE=Dubslow;276406]Man, I've had the crappiest luck on the 45M-50M ranges I've gotten from Mr. P-1. Just one fricken factor in at least 200 tested. Mr. P-1, do the PrimeNet changes obsolete your project? I tested it once with 5 assignments, and they were 56M from 70 to 71. If you have any, I could use another 50.[/QUOTE]

I hope you know about Monsieur Poisson (aka Sod:smile:)

David

'Twas on the good ship Venus
 

[QUOTE=Dubslow;276406]Just one fricken....[/QUOTE]

You've been listening to too many rugby songs.

David

[QUOTE=davieddy;276409]I hope you know about Monsieur Poisson (aka Sod:smile:)

David[/QUOTE]
[QUOTE=davieddy;276410]You've been listening to too many rugby songs.

David[/QUOTE]
You lost me

[QUOTE=Dubslow;276412]You lost me[/QUOTE]
On both counts?
You are really asking for it now!
I'll let Paul do the necessary.

David

[QUOTE=Dubslow;276406]Man, I've had the crappiest luck on the 45M-50M ranges I've gotten from Mr. P-1. Just one fricken factor in at least 200 tested. Mr. P-1, do the PrimeNet changes obsolete your project? I tested it once with 5 assignments, and they were 56M from 70 to 71. If you have any, I could use another 50.[/QUOTE]

I just sent you another 300. Whoops, hope you don't mind. You can always send 250 back.

To answer your question, I'm not sure. I missed last nights grab because I failed to take into account the clock going back. I was an hour late, and by the time I got there, the expiries had all gone. Which is a bit odd. They're not usually all gone in just an hour. Did someone else grab them? Or were they not released? I will try again tonight.

I've just sent new batches to everyone who appears to need them. If I've missed you, sorry about that. Please PM me or post to this thread.

OMG Not more...
 

[QUOTE=Mr. P-1;276435]I just sent you another 300. Whoops, hope you don't mind. You can always send 250 back.

To answer your question, I'm not sure. I missed last nights grab because I failed to take into account the clock going back. I was an hour late, and by the time I got there, the expiries had all gone. Which is a bit odd. They're not usually all gone in just an hour. Did someone else grab them? Or were they not released? I will try again tonight.

I've just sent new batches to everyone who appears to need them. If I've missed you, sorry about that. Please PM me or post to this thread.[/QUOTE]
Double Entendres

David

[QUOTE=Dubslow;276406]Man, I've had the crappiest luck on the 45M-50M ranges I've gotten from Mr. P-1. Just one fricken factor in at least 200 tested. Mr. P-1, do the PrimeNet changes obsolete your project? I tested it once with 5 assignments, and they were 56M from 70 to 71. If you have any, I could use another 50.[/QUOTE]

My experience is similar. 250 exponents since the last factor.

[QUOTE=Mr. P-1;276435]I was an hour late, and by the time I got there, the expiries had all gone. Which is a bit odd. They're not usually all gone in just an hour. Did someone else grab them?[/QUOTE]

That would have been my automated spider, which has been working since Saturday (2011.10.29).

My above proposed system (which I'm calling "GPU to 72") has suffered a bit of "feature creep", but will later today be ready for beta testing by "Workers".

Please PM me if you'd be willing to test the system. (Mr. P-1 and Garo, you are already on my list.)

Excellent.</Mr. Burns>

I noticed many smaller expiring exponents going to "GPU Factoring". I guessed it must be you.

[QUOTE=chalsall;276473]That would have been my automated spider, which has been working since Saturday (2011.10.29).

My above proposed system (which I'm calling "GPU to 72") has suffered a bit of "feature creep", but will later today be ready for beta testing by "Workers".

Please PM me if you'd be willing to test the system. (Mr. P-1 and Garo, you are already on my list.)[/QUOTE]
I'd be willing, but I'm set for the next week or two.

[QUOTE=Mr. P-1;276435]I just sent you another 300. Whoops, hope you don't mind. You can always send 250 back.

To answer your question, I'm not sure. I missed last nights grab because I failed to take into account the clock going back. I was an hour late, and by the time I got there, the expiries had all gone. Which is a bit odd. They're not usually all gone in just an hour. Did someone else grab them? Or were they not released? I will try again tonight.

I've just sent new batches to everyone who appears to need them. If I've missed you, sorry about that. Please PM me or post to this thread.[/QUOTE]
Lol, in America, due to a recent (past couple of years) law change, our time doesn't fall back until next week. :loco::grin:

[QUOTE=garo;276467]My experience is similar. 250 exponents since the last factor.[/QUOTE]

I found 2 in my first batch of 100. Not rubbing it in or anything :P

ETA - from Mr. P-1's efforts, in the ~50million range

[QUOTE=kjaget;276500]I found 2 in my first batch of 100. Not rubbing it in or anything :P

ETA - from Mr. P-1's efforts, in the ~50million range[/QUOTE]

In the last few days I found two in a row, back to back prime exponents, but it was for ckdo in the 28M range.

[QUOTE=Dubslow;276494]I'd be willing, but I'm set for the next week or two.[/QUOTE]
Make that exactly two weeks. Rough estimation and Wolfram Alpha puts completion of current worktodo file on November 15th.

Is it possible to manually unassign the exponents that I do not have in worktodo.txt (I deleted them from the file) but they are still in [url]http://mersenne.org/manual_extension/[/url] ?
There is no "unassign" option at that page and when I want to unassign an exponent via mprime manually, it tells me that it is not in worktodo file.

[QUOTE=Wizzard;276572]Is it possible to manually unassign the exponents that I do not have in worktodo.txt (I deleted them from the file) but they are still in [url]http://mersenne.org/manual_extension/[/url] ?
There is no "unassign" option at that page and when I want to unassign an exponent via mprime manually, it tells me that it is not in worktodo file.[/QUOTE]
You can unassign them. Log-in to your PrimeNet account. Click on Assignments. You will be presented with a list of your current assignments. Check the box next to those that you wish to drop. Click the box at the bottom that says "Unreserve checked exponents".