[QUOTE=Madpoo;407717]This reminds me... can you alter the frequency that save files are generated from 30 minutes to maybe 5 minutes in an attempt to lower the impact of these rollback/retry cycles?[/QUOTE]

It would be great if P95 can be made to save a copy of the FFT _in memory_ every 100-1000 iterations, so that such restarts can be done really efficient (also useful in case of a "prime found" scenario).

The objective of savefile is to not lose work in case of improper shutdown, so it is not really the most optimal solution in this scenario. It is being used just because "it's there".

[QUOTE=Prime95;407716]1) You get a roundoff > 0.4 on iteration X
2) Prime95 rolls back to the last save file
3) When you get to iteration X again, on good hardware prime95 expects to get a roundoff > 0.4 error again. However, this is not guaranteed.[/QUOTE]

Yes, I get that - in fact my program now also uses a similar scheme to support auto-upping of the FFT length if the default breakpoint proves overly aggressive for the user's current p. My question to S485122 was whether by 'second time' he was referring to step (3) in your above flow, that is, the second run of the same checkpoint-anchored iteration subinterval.

But - could you clarify 'this is not guaranteed'? If there has been no data corruption, i.e. the ROE in (1) is 'genuine', what could possibly change on rerun of the subinterval to yield a different ROE on the iteration in question?

[QUOTE=ewmayer;407725]But - could you clarify 'this is not guaranteed'? If there has been no data corruption, i.e. the ROE in (1) is 'genuine', what could possibly change on rerun of the subinterval to yield a different ROE on the iteration in question?[/QUOTE]
See Post 109

[QUOTE=ewmayer;407713]Sorry if I am misunderstanding some detail here - just happened across last few posts here and too busy/lazy to read back in time - but wouldn't one need the 'second time' to establish reproducibility? Or are you referring to 'second time' in the sense of second 'hit-error/restart-from-last-savefile/see-if-retry-hits-same-error' program-flow cycle?

Thanks,
-Ernst[/QUOTE]An iteration provokes a round-off error, the program starts again from the last save file, at the same iteration it gets a round-off error again (same round off as far as they are shown on screen and in the log file), the program restarts from the last save file and, then only, it concludes the error is reproducible. See the excerpts from the log file sin my first post on the subject.

Jacob

[QUOTE=S485122;407727]An iteration provokes a round-off error, the program starts again from the last save file, at the same iteration it gets a round-off error again (same round off as far as they are shown on screen and in the log file), the program restarts from the last save file and, then only, it concludes the error is reproducible. See the excerpts from the log file sin my first post on the subject.[/QUOTE]

Thanks - so it really is the second retry, one more than should be required.

Note that before prime95 redoes the problematic iteration it writes a new save file. So on the third retry (the one where a slower method is used for extra safety) only the problematic iteration is redone.

Thus, if you are using the standard 30 minute save file write time, the time lost due to a roundoff error averages 15 minutes.

[QUOTE=Prime95;407793]Note that before prime95 redoes the problematic iteration it writes a new save file. So on the third retry (the one where a slower method is used for extra safety) only the problematic iteration is redone.

Thus, if you are using the standard 30 minute save file write time, the time lost due to a roundoff error averages 15 minutes.[/QUOTE]

Gotcha. In my brain I imagined it could get a round-off error just 1 second before it's next time to save the interim file, so it would roll back a full 30 minutes. Then I was thinking it would (hopefully) repeat the problem and roll back the full 30 minutes *again* using the safer method.

Knowing that it wouldn't go back to that same 30-minutes ago save file and uses something more recent is good, plus it makes me feel just fine about setting the save file time to 10 minutes (or less).

Believe it or not, I can actually remember back to when the save file size and the time it took to write it was an issue (like '97 or '98 I guess?). I even remember running it from a floppy at times so that my Prime95 was portable... saving the interim files was a much bigger deal and not something to do that often. :smile:

Now that I think about it, why is it set to 30 minutes by default? :confused: Just a legacy thing I suppose?

If I may also ask, why are save files limited to three?

One can write a batch file that wakes up every 5 minutes and, if it finds a "*.bu" (or a "*.bu2", etc) file will rename it to "*.iteration.bkk" (or bk1, etc) then go back to sleep, so you can very easy keep all the history if you want. About the "30 minutes" default time, this makes only sense when your power management does not turn the hdd off periodically. In windoze, that is set to 20 minutes by default, so if you didn't play with it, and didn't switch to SSD meantime, than the life of your HDD will be significantly shortened by the fact that every 20 minutes the HDD is turned off by PM, just to be spun again 10 minutes later by P95. This is case the computer stays idle during p95 is running, because when you edit your docs or play your game, the HDD may have no time to spin off.

[QUOTE=LaurV;407803]... the life of your HDD will be significantly shortened by the fact that every 20 minutes the HDD is turned off by PM, just to be spun again 10 minutes later by P95.[/QUOTE]Are you sure this reduces the lifetime of the HDD? Wouldn't the fact that it is running a duty cycle of only 666‰ increase the lifespan by 50%? No?

The life time of (almost) any electronic device (from light bulbs to including your HDD) is longer if it runs continuously than if you repeatedly turn them on/off. The most of the devices that get damaged ("the most" like in 99%, but take this with a grain of salt, I have no data to back this up, it is just a "feeling"), they get damaged when you turn them on or off. How many of you have seen a light bulb booming during it was lighting, and how many of you happened to turn a light bulb on just to see/hear it booming. The HDD is just the same: spinning it up repeatedly means that the head has to be parked, then it has to be brought to floating position again (there are no "springs" to keep the head out of the disks' surface, this is done by "ground effect", during the disk spins, some air goes between the head and the plate, due to the aerodynamical form of the head, lifting the head up), and during this process there are more chances that the plate can be scratched. In fact, there is a (destructive) HDD test that the manufactures are doing (like Western Digital, they have a factory in Thailand and we used to buy HDDs from them for one of our industrial terminals) which counts how many times the head can be parked and floated again before the plate is scratched. You will be amazed of how "small" is this number! (and no, not in the context of "small numbers" RDS is thinking about :razz:). Of course, this does not count other "effects" as thermal stress (expansion), variation in the frequency of vibrations, etc.

[edit: one of my colleagues reading this says: "C'mon, in few minutes, a good HDD does not have time to stop, friction is so small that it would continue to rotate for longer time after you cut the power", I don't know if this counts for me or for you, hehe, but the head is parked, anyhow...]