mersenneforum.org Possible extention to the "GPU to 72 Tool" project?
 Register FAQ Search Today's Posts Mark Forums Read

 2011-11-17, 20:38 #144 lycorn     "GIMFS" Sep 2002 Oeiras, Portugal 22·3·127 Posts Nice! And it´s good to know there will be DCs available as well.
2011-11-17, 22:30   #145
Chuck

May 2011
Orange Park, FL

22·32·52 Posts

Quote:
 Originally Posted by chalsall Cute idea. I have created the team "GPU to 72" if anyone wants to join....
Thanks — I joined. The PrimeNet team I was on was so big that the server timed out before any statistics could be displayed.

2011-11-18, 03:05   #146
bcp19

Oct 2011

7×97 Posts

Quote:
 Originally Posted by KyleAskine Unless you find a factor right at that moment!
IF you have mfaktc set up to stop after class instead of after bit level.

2011-11-18, 04:14   #147

"Kieren"
Jul 2011
In My Own Galaxy!

1015810 Posts

Quote:
 Originally Posted by chalsall Cute idea. I have created the team "GPU to 72" if anyone wants to join....
I'm in. Even though I show up here as kladner, my alter ego in the lists is ktony.

2011-11-18, 06:25   #148
davieddy

"Lucan"
Dec 2006
England

2×3×13×83 Posts

Quote:
 Originally Posted by chalsall 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.
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.

2011-11-18, 06:36   #149
LaurV
Romulan Interpreter

"name field"
Jun 2011
Thailand

71·139 Posts

Quote:
 Originally Posted by KyleAskine 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:
 Originally Posted by Dubslow I believe it prints the same to standard out as well as results.txt
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. No idea if this is the best solution, and I am opened to any better idea or suggestion. 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

Last fiddled with by LaurV on 2011-11-18 at 06:47

2011-11-18, 07:56   #150
delta_t

Nov 2002
Anchorage, AK

3×7×17 Posts

Quote:
 Originally Posted by LaurV 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?
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
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]

Last fiddled with by delta_t on 2011-11-18 at 08:13 Reason: Added an example

 2011-11-18, 08:45 #151 Dubslow Basketry That Evening!     "Bunslow the Bold" Jun 2011 40
 2011-11-18, 08:48 #152 LaurV Romulan Interpreter     "name field" Jun 2011 Thailand 268D16 Posts Thank you very much delta_t and Dubslow! (and others who tried to help before). Now is plain clear. Tried already. Last fiddled with by LaurV on 2011-11-18 at 08:49
 2011-11-18, 15:36 #153 ET_ Banned     "Luigi" Aug 2002 Team Italia 483810 Posts 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
2011-11-18, 16:09   #154
chalsall
If I May

"Chris Halsall"
Sep 2002

100111110011112 Posts

Quote:
 Originally Posted by ET_ 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".
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:
 Originally Posted by ET_ Will it be possible to also request LL-D work for double checking on the low exponents in the future?
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... )).

 Similar Threads Thread Thread Starter Forum Replies Last Post MooMoo2 Other Chess Games 5 2016-10-22 01:55 wildrabbitt Miscellaneous Math 11 2015-03-06 08:17 Dougy Math 11 2009-10-21 10:04 nitai1999 Software 7 2004-08-26 18:12

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

Mon Jan 24 03:35:49 UTC 2022 up 184 days, 22:04, 0 users, load averages: 1.20, 1.32, 1.32