mersenneforum.org

mersenneforum.org (https://www.mersenneforum.org/index.php)
-   GPU to 72 (https://www.mersenneforum.org/forumdisplay.php?f=95)
-   -   Possible extention to the "GPU to 72 Tool" project? (https://www.mersenneforum.org/showthread.php?t=16211)

Chuck 2011-11-17 02:17

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

LaurV 2011-11-17 02:35

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

bcp19 2011-11-17 04:29

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

KyleAskine 2011-11-17 05:15

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

LaurV 2011-11-17 06:10

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

Uncwilly 2011-11-17 06:19

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

Dubslow 2011-11-17 06:46

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?

Christenson 2011-11-17 06:58

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.

LaurV 2011-11-17 07:07

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

Uncwilly 2011-11-17 07:09

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

Dubslow 2011-11-17 07:11

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


All times are UTC. The time now is 01:12.

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2021, Jelsoft Enterprises Ltd.