Not Saving

I started Prime95 a few days ago, and every time I turn on my computer, the program is checking the same factors of the same prime over and over (ie, first day it was almost 2% done a 2M exponent, the next day it did the same factors, and the next day too) Why is the program not saving it's progress to pick up from later?

[cheesehead]

Will you please quote the messages you get from Prime95? (I can't quite tell what's going on from what you've described.)

[Uncwilly]

Are there any errors being reported? Did you change defualt settings?
Did you copy Prime95 from a CD?

There is no error messages. When I start up the program in the morning it says "resuming from iteration 627" out of some 7 digit number. it then runs through all the iterations, starting from the first every day. its like its not saving its progress as it goes. i'm running on vista, could that be the problem?

[S485122]

The fact that in Windows Vista the security of the "Program Files" folder and subfolders prohibits writing might be the problem. You have two choices : you can install Prime95 in a folder where you do have write access rights (a sub folder of Documents for instance) or if you are administrator you can change the default security on the directory where Prime95 is installed to allow Users to write.

Jacob

I tried opening the folder and changing the setting off of read-only. Everytime I close the folder, it sets it back to read-only. I'm going to try moving the program to a folder that I created, which should not be read only.

I moved everything into a newly created folder, which Vista automatically set to read-only (thats why it asks permission every time you move, copy, or delete anything, apparently). I started Prime95 today and it resumed from where it left off yesterday, so it seems to have worked. Hopefully it won't reset itself tomorrow.

[Nelson]

This problem cropped up for me too. The "q" save file was also missing and an "r" file was present. I use the "fat32" for other reasons which should not have caused this.

After searching support at Microsoft came up with the "attrib" command to change folder attributes. Files within the folder do not necessarily share the attributes of the folder unless they have been set to do so. After applying "attrib -r +s "Drive:\program files\Prime95" /s /d". It still didn't seem to work. (The path must be included in parentheses because of the space in "program files".)

My next step was to make copies of a (strange to me) file beginning with "r" the letter after "q" renaming the"pfile", so it wouldn't get lost, and naming the copies or "rfile" "p" and "q" according to convention and it now appears to be working correctly. My reasons for using the "r" file were that it was more recent and its size was 10k whereas the "p" file was only 32 bytes and considerably older.

I might add that the problem had never occured in 2 years of testing so I was dismayed to lose about two weeks of work because of it.

Prior to the 2 weeks mentioned I had restarted the test due to a round off error. On 2 occasions round off errors have already been enough to convince me that the results will not have the same residue when allowed to complete as a test without round off errors. Altogether the time lost amounted to about 5 weeks. Hopefully it will now complete without errors and saves repeating double checks in the future..

nelson

[Brian-E]

Originally Posted by Nelson

This problem cropped up for me too. The "q" save file was also missing and an "r" file was present. I use the "fat32" for other reasons which should not have caused this.

After searching support at Microsoft came up with the "attrib" command to change folder attributes. Files within the folder do not necessarily share the attributes of the folder unless they have been set to do so. After applying "attrib -r +s "Drive:\program files\Prime95" /s /d". It still didn't seem to work. (The path must be included in parentheses because of the space in "program files".)

My next step was to make copies of a (strange to me) file beginning with "r" the letter after "q" renaming the"pfile", so it wouldn't get lost, and naming the copies or "rfile" "p" and "q" according to convention and it now appears to be working correctly. My reasons for using the "r" file were that it was more recent and its size was 10k whereas the "p" file was only 32 bytes and considerably older.

I might add that the problem had never occured in 2 years of testing so I was dismayed to lose about two weeks of work because of it.

Prior to the 2 weeks mentioned I had restarted the test due to a round off error. On 2 occasions round off errors have already been enough to convince me that the results will not have the same residue when allowed to complete as a test without round off errors. Altogether the time lost amounted to about 5 weeks. Hopefully it will now complete without errors and saves repeating double checks in the future..

nelson

What precisely happened isn't clear to me, but if a process performing a Lucas Lehmer test is stopped it first writes its data to a file rXXXXXXX, then renames the old pXXXXXXX to qXXXXXXX and the newest rXXXXXXX to pXXXXXXX. It also does the same thing periodically while running. So the r file is the temporary file containing the current status ready to replace the p and q files. For whatever reason it seems that the renaming operation failed.

[Nelson]

Thanks Brian,

it helps some.

Found this http://www.mersenneforum.org/showthread.php?t=6574
which gives a bit more thorough explanation. I think the TF savefile pxxxxxxxx is what caused my problem because I had restarted the test and TF started which had already been completed. After stopping and restarting again it began LL testing but hadn't deleted the save file from TFand the file system considered it still in use and could no longer replace it. Further progress wasn't sved because the r******* was still present an couldn't be overwritten. By way of confirmation the r******* file is no longer in my directory and I didn't delete it.

Learning by doing!

nelson