[QUOTE=Dubslow;278736]I've never had it overwrite any changes I've made while it's running.[/QUOTE]


I always lose the assignments without the hex key, using N/A, unless I reboot, and never have a problem when I have the hex key and add them "live".

Doug

[QUOTE=Dubslow;278736]I've never had it overwrite any changes I've made while it's running.[/QUOTE]

I have.

That's why I got into the habit of automatically stopping mprime before I made any changes.

[QUOTE=drh;278745]I always lose the assignments without the hex key, using N/A, unless I reboot, and never have a problem when I have the hex key and add them "live".[/QUOTE]

So, by extension, if you reboot and use "N/A" as the AID you don't lose the assignment?

Trying to get to the bottom of this.

[QUOTE=chalsall;278747]I have.

That's why I got into the habit of automatically stopping mprime before I made any changes.[/QUOTE]

I use Test/Status after modifying the worktodo.txt file. It works for me. YMMV and this is not officially supported functionality.

I think it's that as long as you completely stop it before it rereads the files, it's fine; that's what I do: reboot Prime95 whenever I make changes. That is to say, it doesn't read the files when it shuts down; so as long as you shut it down immediately after making changes, it can't tell the difference between 'live' updating and updating while it's offline. (This is all conjecture based off of our collective experiences.) That was the difference in lycorn's case; as soon as he immediately rebooted it after updates, instead of waiting 'till it next read the files, it worked fine.
@drh: Do you restart Prime95 when you add assignments 'live'? That's what lycorn and I do.

@petrw1: I'm pretty sure the same applies to all files it reads, by which I mean I'm pretty sure I've modified the other files in the same fashion without loss of data.

Edit: Oh double posting. @Prime95: I've found that if I change worktodo without restarting Prime95 (oh dear) then Test/Status doesn't pick up the changes, hence my theory above.

[QUOTE=Prime95;278749]I use Test/Status after modifying the worktodo.txt file. It works for me. YMMV and this is not officially supported functionality.[/QUOTE]

Hey George. Very nice to hear from you.

I just ran a test on one of my machines to accept a P-1 assignment from "GPU to 72" via worktodo.add, and it worked fine.

Would you agree that rather than using a "not officially supported functionality" method, one should either stop / edit / restart, or use the worktodo.add feature?

What is that feature?

[QUOTE=chalsall;278747]I have.

That's why I got into the habit of automatically stopping mprime before I made any changes.[/QUOTE]

Could there be a difference in behaviours between mprime and Prime95?

[QUOTE=Dubslow;278757]What is that feature?[/QUOTE]

Create a file in the same directory in exactly the same format as worktodo.txt but name it worktodo.add.

Within less than 5 minutes prime95 will notice it is there and add that new work for each worker specified to the end of worktodo.txt...and delete that worktodo.add

[QUOTE=chalsall;278756]Would you agree that rather than using a "not officially supported functionality" method, one should either stop / edit / restart, or use the worktodo.add feature?[/QUOTE]

Not that you asked me but I would recommend this.
Unless you DO NOT want the new work to be added to the END of each worker there is nothing easier/safer than using worktodo.add.

For those unfamiliar with this feature see how-to in previous post

[QUOTE=Dubslow;278757]What is that feature?[/QUOTE]

Quoting from the "whatsnew.txt" file in the mprime distribution (as of Version 25.5 of mprime).

[QUOTE]9) In older versions, editing the worktodo.ini file while mprime was running
sometimes had the desired effect. That is no longer the case. You can
create a worktodo.add file to add work to a running mprime.[/QUOTE]

However, it should be noted it often takes a bit of time (up to 20 or so minutes) for "worktodo.add" to be noticed and incorporated. The file takes the exact same format as worktodo.txt. If you don't have "[Worker #(\d*)]" lines, all the work goes to Worker #1.

[QUOTE=petrw1;278758]Could there be a difference in behaviours between mprime and Prime95?[/QUOTE]

Certainly that's possible, although I would hope not.

They're both derived from the same fundamental code base.

Although there is, of course, differences in the wrapper code.

2 small requests.
 

1. Can you post the "as of time" on the pages/reports (at least worker progress).

2. Speaking of time could you use GMT so your time is in the same time zone as PrimeNet.

Thanks

[QUOTE=petrw1;278759]Create a file in the same directory in exactly the same format as worktodo.txt but name it worktodo.add.

Within less than 5 minutes prime95 will notice it is there and add that new work for each worker specified to the end of worktodo.txt...and delete that worktodo.add[/QUOTE]

LOL... Thanks petrw1. We are on the same wave length.

But, at least with mprime, it can take much longer than five minutes to "see" the file. But it does.

[QUOTE=Dubslow;278751]
I've found that if I change worktodo without restarting Prime95 (oh dear) then Test/Status doesn't pick up the changes, hence my theory above.[/QUOTE]
Precisely. That is the main indication that Prime95 has to be stopped, exited and then restarted whenever you make changes to worktodo.txt with the program running.

[QUOTE=chalsall;278748]So, by extension, if you reboot and use "N/A" as the AID you don't lose the assignment?

Trying to get to the bottom of this.[/QUOTE]

Yes, this is true.

Doug

[QUOTE=drh;278792]Yes, this is true.

Doug[/QUOTE]

Or if you use worktodo.add...then you don't have to reboot prime

Absolutely. I agree it´s the best thing to do.

[QUOTE=petrw1;278793]Or if you use worktodo.add...then you don't have to reboot prime[/QUOTE]

I'll try this at my next opportunity ...

Doug

I've been adding stuff out of order...

[QUOTE=Dubslow;278819]I've been adding stuff out of order...[/QUOTE]

So?

worktodo.add only adds stuff at the end of the current list

[QUOTE=Dubslow;278825]worktodo.add only adds stuff at the end of the current list[/QUOTE]

By definition.

Is that a problem?

I meant that the method won't work for me because I usually put things in out of order. That's why I said "I've been adding stuff out of order..." in response to the discussion about worktodo.add

That explains it...
 

Thanks for discussing this...I didn't realize until now what had happened when a bunch of P-1's disappeared from my worktodo. Now I see that it is best to exit and restart Prime95.

Another item. I haven't paid much attention to teams on this site. Would there be any interest in forming a GPUTO72 team?

Chuck

[QUOTE=petrw1;278730]Someone correct me if I am wrong but I believe Prime95 loads contents of work files such as Prime.txt; local.txt and Worktodo.txt into memory...and hence should NOT be updated while it is running because it seems that when Prime95 is stopped it writes what it has back into the work files overwriting whatever you have changed.

SO I too concur...when you take GPU-to-72 work you either need to use worktodo.add OR stop Prime95 before editing worktodo.txt directly.[/QUOTE]

This is valid for other tasks, like trial factoring, and it is also valid for other applications, like mfaktc. Imagine you factor from 70 to 72 bits. Then your first line in worktodo file is something like "factor.....70,72...."
Somewhere in the middle you finish the exponent to 71. Then the result is reported, and the file is MODIFIED, that is its first line will change to "factor .... 71,72", so in case of a restart or power failure, it won't do the "70 to 71" bit again. If you do the last bit, then the line is deleted at all.

But the access to text files is sequential. To modify a line, you have to rewrite all the file (think about adding characters to a line, you can't do that on disk without "pushing away" the following lines, they are stored sequentially, without empty spaces where you could insert your new characters). So, the application reads the file into the memory, does its work, and when the work is done, if the file has to be modified (like changing the bits or deleting assignments) then the application modifies the copy of the file in the memory (where it can directly access the bytes) and save the resulted modified file on the disk. Whatever changes you did meantime are lost. Of course, it could read, compare, etc, judge for itself, and eventually notify/ask you what you want to keep, but this would be just losing a lot of time if you are not in the front of the computer to reply. These programs are done to be "set and forget", and "work in background and do not bother me".

So the best practice is to stop the application, gracefully exit, allow it to save its data, then modify the files, then restart the application.

[QUOTE=LaurV;278837]This is valid for other tasks, like trial factoring, and it is also valid for other applications, like mfaktc. Imagine you factor from 70 to 72 bits. Then your first line in worktodo file is something like "factor.....70,72...."
Somewhere in the middle you finish the exponent to 71. Then the result is reported, and the file is MODIFIED, that is its first line will change to "factor .... 71,72", so in case of a restart or power failure, it won't do the "70 to 71" bit again. If you do the last bit, then the line is deleted at all.

But the access to text files is sequential. To modify a line, you have to rewrite all the file (think about adding characters to a line, you can't do that on disk without "pushing away" the following lines, they are stored sequentially, without empty spaces where you could insert your new characters). So, the application reads the file into the memory, does its work, and when the work is done, if the file has to be modified (like changing the bits or deleting assignments) then the application modifies the copy of the file in the memory (where it can directly access the bytes) and save the resulted modified file on the disk. Whatever changes you did meantime are lost. Of course, it could read, compare, etc, judge for itself, and eventually notify/ask you what you want to keep, but this would be just losing a lot of time if you are not in the front of the computer to reply. These programs are done to be "set and forget", and "work in background and do not bother me".

So the best practice is to stop the application, gracefully exit, allow it to save its data, then modify the files, then restart the application.[/QUOTE]

You are right and wrong here... to edit mfaktc you do need to glance at how much time is left in the current run and figure out if you think you can make the changes in that amount of time or you can save old data, but mfaktc does not read the entire file into memory and store it. I have had mfaktc running non stop for about a week on the one system, and every 2-3 days I visit the gpu website, get 10 more exponents, edit the worktodo and save it. As long as I have more than 5 min on the 'clock' I'll make the change.

[QUOTE=bcp19;278847]You are right and wrong here... to edit mfaktc you do need to glance at how much time is left in the current run and figure out if you think you can make the changes in that amount of time or you can save old data, but mfaktc does not read the entire file into memory and store it. I have had mfaktc running non stop for about a week on the one system, and every 2-3 days I visit the gpu website, get 10 more exponents, edit the worktodo and save it. As long as I have more than 5 min on the 'clock' I'll make the change.[/QUOTE]

Unless you find a factor right at that moment! :smile:

[QUOTE=bcp19;278847]You are right and wrong here... to edit mfaktc you do need to glance at how much time is left in the current run and figure out if you think you can make the changes in that amount of time or you can save old data, but mfaktc does not read the entire file into memory and store it. I have had mfaktc running non stop for about a week on the one system, and every 2-3 days I visit the gpu website, get 10 more exponents, edit the worktodo and save it. As long as I have more than 5 min on the 'clock' I'll make the change.[/QUOTE]

This is known, and debated on the forum. Try editing the FIRST line and changing the bitlevels. The programmer of mfaktc did special precautions (following the discussion on the forum, or at least this I understood after reading all the thread, it is fresh in my mind, I just installed mfaktc, see my posts from 2-3 days ago), to allow the user to modify the worktodo during running, but you are NOT ALLOWED to touch the first line, especially when you have multiple-bit jobs. He saves the last bit there after every completion of it, and if you don't know what you are doing, it is easy to miss a bit level, or repeat already done work, or confuse him at all, whatever. This is that "special features" I was talking in the former post when I said "read, compare, judge for itself". Mfaktc is DOING that. This is not "general behavior" of such programs, but a "special feature". And for your inner peace, I am also editing the worktodo files of mfaktc in exactly the same manner you said - having 5 instances currently, 3 of them crunching for re-checking assignments from Dubslow (the possible-bad reports of no-factor from iconized) and two for GPU-2-72 - watching the wibndows - watching the clock - if enough time left... etc. I have 5 folders called MF1 to MF5, each of them a copy of mfaktc inside, with its worktodo file. In the parent folder I made a small batch called "collect.bat" that walks through all 5 folders and collects the "results" files, if they exists, add them to a file in the parent folder, called "results.all" and then delete them. So at the end I only need to doubleclick the collect.bat, report the things from report.all, delete it, and don't need to manually walk through all the 5 folders to collect results, except when I add work, but that come in large bunches and it needs to be added very seldom.

[QUOTE=Chuck;278835]Thanks for discussing this...I didn't realize until now what had happened when a bunch of P-1's disappeared from my worktodo. Now I see that it is best to exit and restart Prime95.[/QUOTE]Actually, just right click on the icon, stop Prime95, make the changes to worktodo.txt, continue. I do it all of the time.

I think anybody tinkering with worktodo would be smart enough not to mess with the first line, the current assignment. I certainly don't.

@Chuck: I would be, but I know at least petrw1 and I are already on another mersenneforum.org related team (admittedly just a team for team's sake, not any real affiliation.) petrw1, your thoughts?

The actual processing of worktodo inside mfaktc at the moment is that worktodo is opened, read for the assignment to do, and closed. When the assignment is done, worktodo is opened, read for the matching assignment, which is modified, and a new worktodo is written which is a copy of the first except for the modified line.

However, when I ever get to doing automation, worktodo will be something you need to pause mfaktc before trying to write to, as you may or may not be able to predict when mfaktc is going to communicate with primenet and need to append worktodo.

[QUOTE=Christenson;278873]The actual processing of worktodo inside mfaktc at the moment is that worktodo is opened, read for the assignment to do, and closed. When the assignment is done, worktodo is opened, read for the matching assignment, which is modified, and a new worktodo is written which is a copy of the first except for the modified line.

However, when I ever get to doing automation, worktodo will be something you need to pause mfaktc before trying to write to, as you may or may not be able to predict when mfaktc is going to communicate with primenet and need to append worktodo.[/QUOTE]

OTOH, you just detailed "read, compare, judge" from my post.

Related to the second part of your post:

Totally agree. Additionally, when reporting, you have to deal with the situation mfaktc found a factor just after you read the result file, and write it to the file just before you delete it. The factor will be lost. With how many candidates per second a GPU is testing, this is quite probable.

Dealing with worktodo (input) and reporting results (output) are two different matters.

[QUOTE=Dubslow;278870]I think anybody tinkering with worktodo would be smart enough not to mess with the first line, the current assignment. I certainly don't. [/QUOTE]Again, if you just stop Prime95 for a moment and continue, even the first line is not a problem. I pick up new exponents all of the time and use James H's tool to sort the updated worktodo.txt.
The process is:[LIST][*]select exponents[*]build worktodo.add[*]stop Prime95[*]continue Prime95 (causing it to ingest worktodo.add[*]perform a manual communication to get AID's[*]open the updated worktodo.txt in Notepad[*]use James H's [URL="http://mersenne-aries.sili.net/balance.php"]worktodo balancer[/URL][*]stop Prime95[*]paste updated worktodo.txt data[*]save worktodo.txt[*]continue Prime95[/LIST]Takes a minute or 2 (mainly depends upon the speed of the user.

I was refering to mfaktc (suppose I should have mentioned that :redface:)

[QUOTE=Uncwilly;278875][LIST][*]perform a manual communication to get AID's[/LIST][/QUOTE]

[offtopic]
I thought AIDS you can't get by doing manual...
This reminds me of an interview with [URL="http://en.wikipedia.org/wiki/Grigore_Moisil"]The Big Man[/URL], many years ago on the Romanian television. He was talking about "how the world will look in the future", and he was amazing right in predicting how the computers and computer science in general will evolve in the next 50 years, at a time when noone knew what a computer is, and even most of the scientists used to call them "automata". He launched in some explanations about how all the things will change in 50 years (what we can really see today), with personal computers in every house, industrial robots, robots in the house and processors in your car (even that time they were not called processors) and so on. And almost all the human activities will become more or less automatized. At a point, the girl running the show interrupted him and asked something like (sorry for my bad English, I can not really translate that without losing some of the meaning): "Professor, how about the love? How do you see the love in the future?", and with his unbeatable smile, he instantly replied "Sorry to say, little lady, but the love has been, it is, and it will remain in the future... manual".
[/offtopic]

[QUOTE=petrw1;278765]1. Can you post the "as of time" on the pages/reports (at least worker progress).

2. Speaking of time could you use GMT so your time is in the same time zone as PrimeNet.[/QUOTE]

Done. Current time is shown in the upper left hand corner of all pages. All time stamps (Assigned, Completed) are now UTC.

[QUOTE=Dubslow;278830]I meant that the method won't work for me because I usually put things in out of order. That's why I said "I've been adding stuff out of order..." in response to the discussion about worktodo.add[/QUOTE]

Then you get to do plan B :smile:

1. Stop Prime95 (mprime)
b) Add the lines to worktodo.txt
III: Start Prime95

[QUOTE=Dubslow;278870]@Chuck: I would be, but I know at least petrw1 and I are already on another mersenneforum.org related team (admittedly just a team for team's sake, not any real affiliation.) petrw1, your thoughts?[/QUOTE]

Sorry, I have to stay with my current Team as I created it.
Besides without a GPU my contributions are on the low end anyway.

Another thought: I assume (or ASS-U-ME) the purpose of forming a GPUto72 team would be to capture/report its contribution to GIMPS;
However...there is no way for the server to distinguish work I do for GPUto72 vs any other work I do.

[QUOTE=Chuck;278835]Another item. I haven't paid much attention to teams on this site. Would there be any interest in forming a GPUTO72 team?[/QUOTE]

Cute idea. :smile:

I have created the team "GPU to 72" if anyone wants to join....

Short question: How does mfaktc reacts when it finds a factor?

(long version) I am specially interested if it prints something on the screen in real time (that is, when the factor was found, and not after the bit level or class is finished, and I don't care about the result.txt file, in fact it should be better to save the factors found in another file, as the result.txt is repeatedly deleted by my script after every report). So I am interested only if it prints something on screen in real time. Obviously I did not find any factor yet...

[QUOTE=chalsall;278946]Cute idea. :smile:

I have created the team "GPU to 72" if anyone wants to join....[/QUOTE]

As of last report:

245 GPU to 72 1.006

[QUOTE=LaurV;278957]Short question: How does mfaktc reacts when it finds a factor?

(long version) I am specially interested if it prints something on the screen in real time (that is, when the factor was found, and not after the bit level or class is finished, and I don't care about the result.txt file, in fact it should be better to save the factors found in another file, as the result.txt is repeatedly deleted by my script after every report). So I am interested only if it prints something on screen in real time. Obviously I did not find any factor yet...[/QUOTE]

Looking at the source code (for mfakto admittedly, but mfaktc should be similar), it prints the exact same thing to results.txt and the screen at the same time (assuming you have it flagged to stop when it finds a factor):

[QUOTE]if((mystuff->mode == MODE_NORMAL) && (mystuff->stopafterfactor >= 2))
{
fprintf(resultfile, "found %d factor(s) for M%u from 2^%2d to 2^%2d (partially tested) [%s %s]\n", factorsfound, exp, bit_min, bit_max, MFAKTO_VERSION, kernelname);
printf( "found %d factor(s) for M%u from 2^%2d to 2^%2d (partially tested) [%s %s]\n", factorsfound, exp, bit_min, bit_max, MFAKTO_VERSION, kernelname);
}
else
{
if(mystuff->mode == MODE_NORMAL) fprintf(resultfile, "found %d factor(s) for M%u from 2^%2d to 2^%2d [%s %s]\n", factorsfound, exp, bit_min, bit_max, MFAKTO_VERSION, kernelname);
if(mystuff->mode != MODE_SELFTEST_SHORT)printf( "found %d factor(s) for M%u from 2^%2d to 2^%2d [%s %s]\n", factorsfound, exp, bit_min, bit_max, MFAKTO_VERSION, kernelname);
}
}
else
{
if(mystuff->mode == MODE_NORMAL) fprintf(resultfile, "no factor for M%u from 2^%d to 2^%d [%s %s]\n", exp, bit_min, bit_max, MFAKTO_VERSION, kernelname);
if(mystuff->mode != MODE_SELFTEST_SHORT)printf( "no factor for M%u from 2^%d to 2^%d [%s %s]\n", exp, bit_min, bit_max, MFAKTO_VERSION, kernelname);
}[/QUOTE]

[CODE]M57863357 has a factor: 1070462947405609894111
found 1 factor(s) for M57863357 from 2^69 to 2^70 [mfaktc 0.17-Win barrett79_mul32][/CODE]
I believe it prints the same to standard out as well as results.txt

This example is one of the ones that iconized found (the only factors I had handy)

[QUOTE=chalsall;278690]

It's in the works. But it's going to be a few more days.
I have "real" work which has to be done too.... :smile:[/QUOTE]

Fair enough. I didn´t mean to be pushy, by any means...

[QUOTE=lycorn;278974]Fair enough. I didn´t mean to be pushy, by any means...[/QUOTE]

Not taken as pushy. It's a legitimate question.

Currently, "GPU to 72" releases back to PrimeNet exponents once LL candidates have been TFed to at least 72 "bits" (or DC candidates to 69), and have been P-1ed.

Over this weekend the system will keep the lowest 100 candidates for both LL and DC available for reassignment to trusted LL / DC Workers. The rest will simply be released back to PrimeNet to assign as it deems appropriate (read: "first come, first served").

We will adjust the numbers held as we get a feel of the "firepower" available.

Nice! And it´s good to know there will be DCs available as well.

[QUOTE=chalsall;278946]Cute idea. :smile:

I have created the team "GPU to 72" if anyone wants to join....[/QUOTE]

Thanks — I joined. The PrimeNet team I was on was so big that the server timed out before any statistics could be displayed.

[QUOTE=KyleAskine;278852]Unless you find a factor right at that moment! :smile:[/QUOTE]

IF you have mfaktc set up to stop after class instead of after bit level.

[QUOTE=chalsall;278946]Cute idea. :smile:

I have created the team "GPU to 72" if anyone wants to join....[/QUOTE]

I'm in. Even though I show up here as kladner, my alter ego in the lists is ktony.

[QUOTE=chalsall;278982]
Currently, "GPU to 72" releases back to PrimeNet exponents once LL candidates have been TFed to at least 72 "bits" (or DC candidates to 69), and have been P-1ed.

Over this weekend the system will keep the lowest 100 candidates for both LL and DC available for reassignment to trusted LL / DC Workers. The rest will simply be released back to PrimeNet to assign as it deems appropriate (read: "first come, first served").

We will adjust the numbers held as we get a feel of the "firepower" available.[/QUOTE]
My 45M LL will "prove" to be composite in ~24 hours time.

Seeking similar.
No probs with doing the P-1.
Don't worry about the TF level.

David

PS: Smoking obligatory.
PPS: No timewasters please.

[QUOTE=KyleAskine;278962]Looking at the source code (for mfakto admittedly, but mfaktc should be similar), it prints the exact same thing to results.txt and the screen at the same time (assuming you have it flagged to stop when it finds a factor):[/QUOTE]

[QUOTE=Dubslow;278973]I believe it prints the same to standard out as well as results.txt
[/QUOTE]

When? Obviously I don't stop after a factor is found, otherwise I will not need to know the answer.

I take my assignments from Dubslow and from GPU272 and run them to completion, never stopping the mfacktc. But I do report the results meantime, otherwise it will take ages if I would want to report all when it finishes. In fact, never finishes, because I always add new assignments to worktodo files. So, I MUST report the results from time to time. First thing.

Second, to saturate my GPU's, I need to run multiple copies of mfaktc. For that I create a "parent folder", and inside of it I made different folders, MF1, MF2, etc, for how many copies of mfaktc I run, and put inside a copy of the executable, the library and the .ini file. [B]No idea if this is the best solution, and I am opened to any better idea or suggestion.[/B] This is just how I handle it currently, and I do not claim that the solution is good/better/thebest. In fact is bad, because all the worktodo files are now in separate folders, and I have to manually walk through them to add (and equally split it between them) new work to do from time to time. And it became worse for reporting the results, which I do more often.

That is why I did a small batch file and place it in the parent folder. This small batch file is walking through all the MFx folders and looks for a "results.txt" file. If it finds one, copy its content in parent folder, in a file called "results.all", and delete the "results.txt" to avoid double reporting. Everything works perfect now, and the only things I need to do is to double click on this batch file, then report the contents from "results.all" whenever I kike, and if I already reported it, then I delete it. That is all. Execution of the batch file takes less then a second, so I need to check only if one of the mfaktc windows are not at the last iteration, in such case I would risk to delete some results.txt file in the same time mfaktc finishes the job and wants to write into the results.txt file (therefore losing some results, or whatever unknown situation could result from it).

Now the problem is "what happens when mfaktc finds a factor?". It can either:
1. write a factor into results.txt AND on screen in the same time, at the moment when the factor is found.
2. write the factor on screen only, and write it to the results.txt when the class is completed.
3. write the factor on screen only, and write it to the results.txt when the bitlevel is completed
4. write the factor on results.txt immediately, and write it to the screen when the class is completed.
5. write the factor on results.txt immediately, and write it to the screen when the bitlevel is completed.
6. write the factor on screen AND on results.txt when the class is completed
7. write the factor on screen AND on results.txt when the bitlevel is completed
8. any combination of 6 and 7 above, I don't want to add any more bullets to the list.
9. write the factor on results.txt only (obviously it must be written there) whenever he likes, but never on the screen.


The most probable is in order, 1, 6, 5. The rest are less probable, because I don't believe it "splits" the writings between different moments of time.

Now, for me, the only "ugly" situations are number 5 and number 9. For all the other I CAN NOT miss the factor. I mean, I am there, looking to the screen with two BIG and CURIOUS eyes, and for a class to finish need only few seconds, so if the factor IS printed on the screen when it is found, or at the end of a class, then I CAN see the factor on screen, and check if I have it in the "results.all" file. If not, I will copy it from the screen (use the mark/copy/paste function for dos prompt windozes).

But is situation 5 (factor is printed on screen at the end of the bitlevel, this makes sense because maybe the writing is handled by the program only when the bitlevel ends, to save time, or the programmer did not want to disturb the nice tabular data on screen), or in the situation 9 (factor never appears on screen, this also makes sense if the programmer did not want to "disturb" the nice tabular data on screen), then I could miss the factor, if the results.txt gets deleted (by the batch file) EXACTLY in the moment AFTER a factor is written to it, but it was read and copied BEFORE the new factor to be added to it.

I mean, imagine the next scenario that take place during not more than a couple of milliseconds: I looked on all the screens for all the copies of mfaktc, and I saw that no one is "almost finished" with its bitlevel, so I launch the batch file. This reads some "result.txt" file from a child folder and starts copying it to "results.all" in the parent folder. Then mfaktc finds a factor and puts it in the results.txt, but does not put it on the screen. Then the batch file continue its job by deleting the "result.txt". Factor lost.

Now you see my problem? So, the question is very simple: did any of you have seen with his own eyes a factor printed on screen "between" the rows of the tabular data with the classes? That is, a factor printed on screen immediately after it was found, or after the class ends? Assuming the program is set to "finish the bitlevel, do not stop after the factor is found".

Did you?

Simple answer, yes or no. No need to go into details. Because if the answer is "no", then I need to go into much more details with my batch file (to take precaution against deleting the file, eventually rename it, and not delete it, I can not lock it for access because I don't know how mfaktc will react when it tries to write a locked file).

And thanks for the patience to read all the gibberish I wrote in this post :D

[QUOTE=LaurV;279022]
Now you see my problem? So, the question is very simple: did any of you have seen with his own eyes a factor printed on screen "between" the rows of the tabular data with the classes? That is, a factor printed on screen immediately after it was found, or after the class ends? Assuming the program is set to "finish the bitlevel, do not stop after the factor is found".

Did you?
[/QUOTE]

Yes I can confirm it writes it to screen and to the results.txt, I've seen it several times. It did it after it was found, and then continued on because mine are set to finish the bit level.

If you want just run this: Factor=490190501,64,66
You will find 2 factors, and can test it out for yourself. It takes 42s on a GTX 460M

Here is the output to screen:

[code]got assignment: exp=490190501 bit_min=64 bit_max=66
tf(490190501, 64, 66, ...);
k_min = 18815892900
k_max = 75263572166
Using GPU kernel "barrett79_mul32"
class | candidates | time | avg. rate | SievePrimes | ETA | avg. wait
91/ 420 | 30.67M | 0.444s | 69.08M/s | 5000 | 0m33s | 172us
Result[00]: M490190501 has a factor: 60404206098872613503
376/ 420 | 30.67M | 0.417s | 73.55M/s | 5000 | 0m04s | 162us
Result[00]: M490190501 has a factor: 43131916492175986793
415/ 420 | 30.67M | 0.422s | 72.68M/s | 5000 | 0m00s | 163us
found 2 factor(s) for M490190501 from 2^64 to 2^66 [mfaktc 0.17-Win barrett79_mul32]
tf(): total time spent: 42.105s[/code]

Here is the output to the results.txt

[code]M490190501 has a factor: 60404206098872613503
M490190501 has a factor: 43131916492175986793
found 2 factor(s) for M490190501 from 2^64 to 2^66 [mfaktc 0.17-Win barrett79_mul32][/code]

It is either immediately or after finishing the class, (options 1 & 6 on your list) and you did not mention them as the problem scenarios. I can't see as it makes more than a second or two difference, and if it does, then just use delta_t's example above to figure out which.

Edit: Hmm... in retrospect, I did not read your original question to the depth I should have. Factors found are written to STDOUT and results.txt immediately or after the class, which is both easily determinable and of little consequence.

Thank you very much delta_t and Dubslow! (and others who tried to help before). Now is plain clear. Tried already.

I lost my mind
 

When I saw that GPU to 72 was showing "Double check work" I asked for a 25M exponent and fired up my CUDALucas on that exponent.
Later on, I understood that the Double check work was intended as "trial-factoring on low exponents".
Will it be possible to also request LL-D work for double checking on the low exponents in the future?

Luigi

[QUOTE=ET_;279071]When I saw that GPU to 72 was showing "Double check work" I asked for a 25M exponent and fired up my CUDALucas on that exponent. Later on, I understood that the Double check work was intended as "trial-factoring on low exponents".[/QUOTE]

Actually, that's more my fault than yours -- my nomenclature is a bit off. The naming schema was designed before the idea of offering true LL and DC work to trusted workers was conceived. I will make the language for the menus and pages more explicit.

[QUOTE=ET_;279071]Will it be possible to also request LL-D work for double checking on the low exponents in the future?[/QUOTE]

Yes, this is scheduled for implementation this weekend.

However, if you PM me the exponent you were doing true DC work on, I will PM you back the "DoubleCheck=..." line with the real AID. This will help me test to ensure the transfer of ownership methodology we hope to use works correctly.

Also, if any other "GPU to 72" Workers are interested in having access to low LL and/or DC work (rather than or in addition to TF work), please PM me or post here. This work type will only be available to workers who are "trusted" (as determined by the amount of such work you've done in the past (or an appropriate amount of begging... :smile:)).

[QUOTE=ET_;279071]When I saw that GPU to 72 was showing "Double check work" I asked for a 25M exponent and fired up my CUDALucas on that exponent.
Later on, I understood that the Double check work was intended as "trial-factoring on low exponents".
Will it be possible to also request LL-D work for double checking on the low exponents in the future?

Luigi[/QUOTE]

Yes, see [url]http://mersenneforum.org/showpost.php?p=278982&postcount=144[/url].

Edit - dang, beaten to the punch.

[QUOTE=chalsall;279077]
Also, if any other "GPU to 72" Workers are interested in having access to low LL and/or DC work (rather than or in addition to TF work), please PM me or post here. This work type will only be available to workers who are "trusted" (as determined by the amount of such work you've done in the past (or an appropriate amount of begging... :smile:)).[/QUOTE]

I would like to work on the low LL/DC please.

Chuck

[QUOTE=davieddy;279021]My 45M LL will "prove" to be composite in ~24 hours time.

Seeking similar.
No probs with doing the P-1.
Don't worry about the TF level.[/QUOTE]

PM sent with a low 45M LL assignment.

(I now understand more deeply why Mr. P-1 got tired of doing this job manually.... :smile:)

[QUOTE=chalsall;279077]
However, if you PM me the exponent you were doing true DC work on, I will PM you back the "DoubleCheck=..." line with the real AID. This will help me test to ensure the transfer of ownership methodology we hope to use works correctly.
[/QUOTE]

Too late... :smile: My exponent is already being processed with CUDALucas, no need of IDs.

I hope I will be able to submit it using the "manual page" of GIMPS.

Anyway, I will be more than happy to help you with the new LL-D assignment procedure as soon as I get back home next Thursday. Please send me a PM with the instructions...

Luigi

[QUOTE=ET_;279094]Too late... :smile: My exponent is already being processed with CUDALucas, no need of IDs.[/QUOTE]

But... If you PM me the exponent I can set it to be a DC work type, and ensure the work completed is picked up by the system.

My first GPU to 72 P-1 factor....
 

.... after only 41 attempts

My first GPU to 72 P-1 factor....
 

.... after only 41 attempts

[QUOTE=petrw1;279100].... after only 41 attempts[/QUOTE]

LOL...

Given 41 flips of a fair coin which turned up heads in a row, what is the probability that the next coin flip will turn up tails? :wink:

Sorry petrw1, I couldn't resist (I'm currently taking an AI course where statistics are being drilled into our head every week). Thanks for using the system, and congratulations for finding a factor. :smile:

My TF to low limits just started getting 43M exponents to TF from 64-65 instead of the 300M ones I had been getting. Is there a way GPU to 72 can get these?

[QUOTE=bcp19;279133]My TF to low limits just started getting 43M exponents to TF from 64-65 instead of the 300M ones I had been getting. Is there a way GPU to 72 can get these?[/QUOTE]

Are you sure this isn't LMH TF work at 430M?

It would make little sense for GPU to 72 to participate in such work.

[QUOTE=bcp19;279133]My TF to low limits just started getting 43M exponents to TF from 64-65 instead of the 300M ones I had been getting.[/QUOTE]

[QUOTE=chalsall;279136]Are you sure this isn't LMH TF work at 430M?[/QUOTE]I have a CPU that is doing TF to low limits. It is working on 300M numbers and has a bunch of 435M's queued up.

[quote]M47782963 has a factor: 1997061982218721676231[/quote]Unfortunately, that was from the series of P-1 assignments that I'm currently working on, so I won't get any GPU72 credit. It'll take me several more weeks to clear out my current queue of assignments before I can start working GPUto72 assignments. Maybe by then I'll have reached my goal of 730 P-1 factors in the past 365 days (2/day) :smile:

[QUOTE=chalsall;279136]Are you sure this isn't LMH TF work at 430M?

It would make little sense for GPU to 72 to participate in such work.[/QUOTE]

That's what it was... For some reason I did not connect the dots. Guess old age is catching up with me ;)

100+ factors.
 

Just noticed we passed 100 factors found :batalov:

109 Factors Found!!!
 

[QUOTE=petrw1;279159]Just noticed we passed 100 factors found :batalov:[/QUOTE]

Yup. I've created a quick [URL="http://gpu.mersenne.info/reports/overall/"]Overal System Status[/URL] report to keep track of the stats; copied below:

[CODE][U]Worktype Factors Found Average GHz Days per Factor Total GHz Days[/U]
DC TF 11 189.638 2,086.028
LL TF 83 310.928 25,807.069
P-1 15 50.439 756.591
[B]Total 109 183.668 28,649.689[/B][/CODE]

Thanks for all the work everyone!!! :cool:

I am taking a short break from the P-1 from your server, since I cannot ever claim any! I am going to work hard on finishing some old LL's that I have reserved from Primenet, and I hope in a few weeks when they are done, more P-1's will be available that I can throw all of my non TF cycles towards!

[QUOTE=KyleAskine;279204]I am taking a short break from the P-1 from your server, since I cannot ever claim any! I am going to work hard on finishing some old LL's that I have reserved from Primenet, and I hope in a few weeks when they are done, more P-1's will be available that I can throw all of my non TF cycles towards![/QUOTE]

There are actually many available for P-1 work... Just none (or at least, none not yet claimed) already TFed to 72. If you change the "Minimum TF level" field to 71, you could claim as many as you like. Know, however, that such candidates may be TFed to 72 once your work is completed, assuming you didn't find a factor.

[QUOTE=petrw1;279101].... after only 41 attempts[/QUOTE]

Hmm.
I thought the P-1 "hitrate" was better than 1 in 40, even after
TF to 72.
Bounds?

I think that was his point.

8-11-11
 

Hi Tom,
I have the memory span of a goldfish these days.
I can't remember whether that means the 8th day of
the 11th month, or the 11th day of the 8th month...or 1908...

...let alone what prompted me to mention the out-of-bounds
daughter of the admiral in the first place.

I know what you mean, but I would be surprised
if anyone else (Paul excepted) did.

Where in the "useless" thread forum did you throw it to?

[URL="http://www.youtube.com/watch?v=AYMyxTFwuz8"]Careful with that axe Eugene![/URL]

David

PS Could you correct the spelling of "extention"
in the title, or is that just the way the colonials spell it?

Already.

[QUOTE=davieddy;277557]See "useless posts" thread from #500 on to understand what
prompted this.
I can't understand why any mod (Tom?) could find
anything remotely suggestive about the admiral's daughter's
naval base being full of discharged seamen.

Pottymouth

[B]fivemack:[/B] Whilst I may have gained an entirely deserved reputation as being swifter with the thread-move button and the great-big-hammer switch than some other mods, I haven't done anything on this thread. Perhaps I have been reading too much Hornblower, but I would have thought the average junior-ranking sailor would rather engage in carnal relations with a polar bear than with the admiral's daughter, the potential for injury and career-threatening consequence being less and the polar bear probably more cuddly.[/QUOTE]

Beta testers requested for real LL and/or DC work from GPU to 72.
 

[QUOTE=chalsall;278982]Over this weekend the system will keep the lowest 100 candidates for both LL and DC available for reassignment to trusted LL / DC Workers. The rest will simply be released back to PrimeNet to assign as it deems appropriate (read: "first come, first served").[/QUOTE]

OK, thanks to davieddy we were able to test the candidate ownership transfer trick we were hoping to use. It didn't work... :sad: It turns out that even with the real AID, ownership is not transferred if the candidate is owned by a registered PrimeNet worker.

However, though some experimentation, I've been able to prove that if the AID is owned by an Anonymous worker, ownership [B][I][U]is[/U][/I][/B] transferred. (So, Mr. P-1, you were half right -- thanks for that lead... :smile:)

Those interested in being assigned low LL or DC work (not Trial Factoring work on LL or DC candidates, but real LL or DC work at the low end of the wave fronts), please PM me with the number of assignments and the work type you'd like. "Spidy" has collected some very nice low candidates which were then TFed up to at least 72 (or 69 for DC) bits by GPUs...

Only one or two per Worker for the time being, please -- this will be a test to ensure that the ownership is properly transferred to you (including with Prime95 which I didn't test) before I make such assignments available via a web interface.

This process should work (it worked for me with mprime), but I always like to have humans in the loop when testing something new before allowing a 'bot to work on its own....

It works!!!
 

Thanks to Chuck for being the first beta tester...

We have now determined that the transfer methodology works for both mprime and Prime95.

Chuck is now the owner (according to PrimeNet) of a bouncing low LL candidate. There is nothing I (or my spider) could do with it from this point forward. Exactly as I wanted. :bounce:

I have a mid-term exam I need to cram for (LOL! I haven't said that for more than 25 years...), so the web-interface for this work type will be a few more days.

But if anyone wants some low LL or DC work TFed to high levels, just PM me.

You sir are awesome.:alien 3:

I'd help, 'cept I'm away from my comp until next Sunday. (Also, sweet!)

[QUOTE=chalsall;279337]Thanks to Chuck for being the first beta tester...

We have now determined that the transfer methodology works for both mprime and Prime95.

Chuck is now the owner (according to PrimeNet) of a bouncing low LL candidate. There is nothing I (or my spider) could do with it from this point forward. Exactly as I wanted. :bounce:
[/QUOTE]

Sounds good to me. What is the trick?

I'm soldiering on, as you instructed, with my(?) 45M LL.
Should be done before the year ends.

I find these collaborations fun!

BTW My original request was supposed to convey that:
1) I would happily have done P-1 if necessary (it wasn't).
2) I would have asked Eric to TF some more bits on his GPU
if necessary, but I considered 71 bits for a 45M expo to be
more or less the state of the art ATM.

David

@Uncwilly... Thank you for your very kind words. It's nice being able to apply my talents to one of my hobbies.

[QUOTE=davieddy;279347]Sounds good to me. What is the trick?[/QUOTE]

The "GPU to 72" spider reserves assignments using the registered user "GPU Factoring". It then "lends" them to GPU and P-1 Workers to work until they are ready to release back "into the wild".

So, to be able to then "officially" transfer low candidates to LL or DC workers, the system needs to release them back to PrimeNet, and then re-request them immediately afterwards using an "Anonymous" account. There's a race condition there, but since we would otherwise release them back to PrimeNet anyway, it doesn't really matter if we lose a few in the process (and because it's all scripted the temporal window is small, but not zero).

Why didn't I just start out by reserving them anonymously? Because I wanted to be able to review the allocated exponents on PrimeNet using the account, and ensure my spider and PrimeNet agreed.

[QUOTE=davieddy;279347]I'm soldiering on, as you instructed, with my(?) 45M LL.
Should be done before the year ends.[/QUOTE]

Excellent. And thanks, again, for being the first Alpha tester. :cool:

I could try the de-register / re-register process with your one assignment, and it would almost certainly work. But I think in this one case we either ask George or Scott to transfer ownership, or I just hold ownership of it until you complete. You will still get the PrimeNet credit.

[QUOTE=davieddy;279347]I find these collaborations fun![/QUOTE]

As do I.

It's nice working with really smart people. :smile:

[QUOTE=petrw1;278737]OK all 9 cores going ... and completing about 8 per day.[/QUOTE]

Adding 4 more cores....hoping to get to 12 P-1 completions per day.

Suggestion for a feature.

Could you add a column in your report that states the GHz-days saved because a factor was found? James H has code that calculates how much is given for LL's.:pancakebunny:

@chalsall: small observation, I saw that your spiders do not detect partial submissions. I took some expos from 66 or 67 to 68, 69,...,71, but not yet to 72 as "promised" in the assignment form when I requested them. My status is not changed, and most probably if I "leave" now the project (I am not intending to! this is just for the sake of the example) then my "credit" is lost.

Second, I just saw the new addition, the page with [URL="http://gpu.mersenne.info/reports/overall/"]Overall System Progress[/URL] and I can't stop asking myself: "Does it worth?"... I mean, 300GHz-days per factor? With the same resources one could run first time LL test for 3 (three) to 4 (four) exponents, and for DC-front (200GHzd per factor) even 5 times more. And we would have 3 or 5 times more cleared exponents. Of course, finding a factor is cool... hehe....indubitable proof... fun...

As someone said in OBD thread, "you have your fun, we have ours". I am still considering about P-1, this seems to be the only rentable part up to now. What a pity it can't be run on GPU's. But CudaLucas CAN!

Don't get me wrong, I am not going to leave (yet :P), in fact I am just about going to start, what you saw up last days since I joined, was just about 20% to 33% from ONE card, the rest of it and the second card being busy with iconized's tests, which I just finished, and with one LL that will finish tonight.

[QUOTE=LaurV;279441]
Second, I just saw the new addition, the page with [URL="http://gpu.mersenne.info/reports/overall/"]Overall System Progress[/URL] and I can't stop asking myself: "Does it worth?"... I mean, 300GHz-days per factor? With the same resources one could run first time LL test for 3 (three) to 4 (four) exponents, and for DC-front (200GHzd per factor) even 5 times more. And we would have 3 or 5 times more cleared exponents. Of course, finding a factor is cool... hehe....indubitable proof... fun...

As someone said in OBD thread, "you have your fun, we have ours". I am still considering about P-1, this seems to be the only rentable part up to now. What a pity it can't be run on GPU's. But CudaLucas CAN!

Don't get me wrong, I am not going to leave (yet :P), in fact I am just about going to start, what you saw up last days since I joined, was just about 20% to 33% from ONE card, the rest of it and the second card being busy with iconized's tests, which I just finished, and with one LL that will finish tonight.[/QUOTE]

The efficiency of GPUs on TF makes it so GHz/days is not a good comparison metric when going across work classes. I promise the project is saving work.

[QUOTE=KyleAskine;279442]The efficiency of GPUs on TF makes it so GHz/days is not a good comparison metric when going across work classes. I promise the project is saving work.[/QUOTE]
I totally believe you, that is why I am staying. I mean, that is what the common sense is telling me, that the project is saving work, otherwise why should a lot of clever people here invest time and resources? But if you ask me to tell you how, then I would lift my shoulders. That is why I brought out the issue, maybe some discussion/arguing will start and from it, I could later understand what is really going on :D

[QUOTE=LaurV;279441]@chalsall: small observation, I saw that your spiders do not detect partial submissions. I took some expos from 66 or 67 to 68, 69,...,71, but not yet to 72 as "promised" in the assignment form when I requested them. My status is not changed, and most probably if I "leave" now the project (I am not intending to! this is just for the sake of the example) then my "credit" is lost.[/QUOTE]

"Spidy" *does" detect partial submissions. The system just doesn't award credit until the pledged work has been completed.

Would you feel more comfortable if the system gave credit for partial work done? I'm inferring yes.

Sigh... Yet more work for me... (Pulls out the "ToDo:" form for this project...)

To put your mind at ease, if you, or anyone, leaves the project you will be credited for the work done (after a month of the assignment being given) on GPU to 72.

But, at the end of the day, the PrimeNet site is authoritative for credit.

[QUOTE=Uncwilly;279439]Could you add a column in your report that states the GHz-days saved because a factor was found? James H has code that calculates how much is given for LL's.:pancakebunny:[/QUOTE][i]chalsall[/i] already has that code, including useful functions like GHzDaysSavedTF() and GHzDaysSavedP1(), but the caveat with that is that it assumes that a factor found by TF saves 1x P-1 and 2x L-L; it does not properly take into account cases like finding a TF factor [i]after[/i] P-1, or finding a factor between 1st L-L and DC, etc (but these are unusual cases than can easily be overlooked for sake of simplicity).

[QUOTE=KyleAskine;279442]The efficiency of GPUs on TF makes it so GHz/days is not a good comparison metric when going across work classes. I promise the project is saving work.[/QUOTE]

Indeed.

GPUs have completely changed the metrics. The more advanced ones produce something like 100 times the output of a CPU for trial factoring. It's a bit like a Battleship circling an Ironclad...

But this is the metric which PrimeNet uses.

James and I are simply calculating what PrimeNet calculates.

[QUOTE=chalsall;279446]
James and I are simply calculating what PrimeNet calculates.[/QUOTE]
Well, I am not really thinking in numbers, I have no idea how they are computed, and I am not really interested to find out today. I am thinking in time.

Say like that, I am TF-ing for GPU272 since 5-6 days and I took 7 exponents from 67-69 to 72 and a couple others to intermediary steps. Meantime, I did not find any factor. In all this time I used say 30% of one of my GPU cards, that could run a LL with CudaLucas in less then 24 hours, for a 25-30M exponent. Now, that would be full power, but in this particular case, with 30%, say it takes 3 days to clear one exponent. In 5-6 days I could clear 2. I cleared none, and the LL still has to be done for all exponents I touched.

Now, endless discussion could go on into the fact that this exponents had plenty of P-1 done on them already, therefore decreasing the chance to find a factor, and that is why I found none, but I could argue that exactly here is the point where the time is NOT saved. For an exponent with no P-1 and no LL, there should be reasonable to TF it to higher and higher limits, because in case when a factor is found, we save plenty of P-1 and 2 (two!) LL tests.

But for lower exponents with one LL and a lot of P-1 done????

To be profitable, this has to produce a factor at every 4-5-6 exponents taken from 67 to 72. That is because one need about 4-5 hours for one expo in the range of 25M (if the exponent is lower, the time is longer, there is about 11 minutes for the first bit, and the time doubles at every bit) on a very fast GPU, that would take 24 hours. If you find a factor, then one LL is saved and you still have to run another 3-4-5 LLs for the other exponents. But if you do not find a factor in these 5 trials, then better you could run CudaLucas and CLEAR one exponent "for sure" in 24 hours. Saving time. Because if you do not find a factor, then you still have to run CL for ALL 6 expos, and the time was just wasted.

And here it come the probability of finding factors for expos that were heavily P-1-ed, which is much lower then 1 in 6. Much lower then one in 10. Much lower then... well.. it is lower... :D

And by doing that, we take "the bread from the mouth" from many old computers involved in the project which are so old that they can do only DC. Reducing DC assignments for lower exponents, on long term, will put such computers out of business.

That is why I can not stop wondering and being a bit grumpy about it...

[QUOTE=LaurV;279449]Say like that, I am TF-ing for GPU272 since 5-6 days and I took 7 exponents from 67-69 to 72 and a couple others to intermediary steps. Meantime, I did not find any factor. In all this time I used say 30% of one of my GPU cards, that could run a LL with CudaLucas in less then 24 hours, for a 25-30M exponent. Now, that would be full power, but in this particular case, with 30%, say it takes 3 days to clear one exponent. In 5-6 days I could clear 2. I cleared none, and the LL still has to be done for all exponents I touched. [/quote]
1. Since first time LL exponents should be taken to 72 and DC exponents should only be taken to 68 bits, I am guessing you're comparing apples and oranges (or did you take DC exponents to 72?! In which case, don't).
2. Statistics -- Specifically, low sample size. ~ 10 exponents is nowhere near a large enough sample size to make any conclusions. [Nonetheless, you were not really expected to find a factor with so few exponents done]

[QUOTE=axn;279451] (or did you take DC exponents to 72?! In which case, don't).[/QUOTE]
:blush: Well... in fact that is what I did... and where my credit was coming from... As the project is called "GPU to [COLOR=Red][B]72[/B][/COLOR]", and I did not find any explanation about where we should stop, I took all my assignments to 72, as you can see on my "view completed" page... Grrrr.... And this is where all the dilemma started... So, I worked in vain... common for me... it happens all the time... :smile:

So, let's start from the beginning:

How far should I take an exponent (TF bit level), depending on its size and former work done, LL, P-1, etc)??? Any tabular data or graphic? Like for dummies?

Edit: and what should I do with about 140 DC expo already reserved, waiting to be factored to... 72, in my worktodo? (I think let them finish is better, I am lazy to edit the file and this will complicate the things, as I have to return them to the project and reserve them again with a lower bound??)

Edit edit: for (2), I know the "statistics" part, that wasn't the point of my post. You can take first 3-4 people from the top of the status report on the project's page, who returned thousands of exponents, and tell me about it. Their "statistics" are even worse then mine, if I put in the GPU time spent.

72 for first time LL's, 68 for DC. Keep in mind that it also takes twice as long to do a DC exponent at a certain bit depth as the 45M first timers.

You were right to consider time, instead of GHz-days. Divide the GHz-Days/Factor by 100, and that's the 'GPU-Days' (give or take, my card being mid range and capable of ~100GHz-Days/Day). The GPU-Days per factor (around 3.5, according to the most recent data) is a [I]lot[/I] less than days per LL test. With CUDALucas thrown into the mix it's not as shocking a gap, but for my 100GHzDay/Day graphics card, it takes about ~15 days to LL test a similar sized exponent (not DC) so that's still 5 times as many factors as LL tests.

[QUOTE=LaurV;279452]:blush: Well... in fact that is what I did... and where my credit was coming from... As the project is called "GPU to [COLOR=Red][B]72[/B][/COLOR]", and I did not find any explanation about where we should stop, I took all my assignments to 72, as you can see on my "view completed" page... Grrrr.... And this is where all the dilemma started... So, I worked in vain... common for me... it happens all the time... :smile:[/quote]

Well, the rule of thumb is "4 bits less for DC than for LL". Since we're taking first time tests to 72 (why the project was called "GPU to 72"), it follows that we should take DC's to 68. But [URL="http://www.mersenne.info/trial_factored_tabular_delta_7/1/0/"]here[/URL], I see that most people are taking it to 69. Which is probably not advisable. [Alternatively, if it _is_ worth taking DC to 69, then it is worth taking first time LL to 7[B]3[/B]]

[QUOTE=LaurV;279452]Edit: and what should I do with about 140 DC expo already reserved, waiting to be factored to... 72, in my worktodo? (I think let them finish is better, I am lazy to edit the file and this will complicate the things, as I have to return them to the project and reserve them again with a lower bound??)[/QUOTE]

That would be a colossal waste of resources. Can you coordinate with chalsall to see how best to handle this? As you said, you're probably better off DC-ing them outright, rather than taking them to 72 bits.

I think, then, the next question is why not go further then 72; there are (à mon avis) two answers. The first is breadth; get the most exponents done, rather than highest bit-level; the other answer is that the above analysis ignores things like 'mfaktc takes a CPU core' (--> CUDALucas + plus the extra core means <15 days per test) and 'my CPU can do 4 tests at once' instead of one instance of mfaktc.

Oops, double posted. This is in response to my previous post, not having noticed axn's.