Windows S5R4 App 6.06 available for Beta Test

In case people haven't noticed, I'd like to draw attention to an edit that Bernd has placed in the opening message.

I've converted a number of "SSE" machines running Windows to the 6.06 app so I now have direct experience with the new checkpointing problem. Since I use the preference to "keep apps in memory when preempted" and the machine runs 24/7, there is mostly no problem with the fact that only the very first checkpoint for a task ever gets written. This is also true when the machine switches between projects, since once again the preempted task is kept in memory until the next time slice commences. It is fortunate that the task always residing in memory means that a checkpoint isn't usually going to be needed. If you don't have that preference set, any cycling between projects would not allow useful progress to be made on the EAH task as every time a new time slice commenced, the original (and very much out of date) checkpoint would always be reloaded.

There are at least two other situations in which this new bug will give problems. Firstly, if you don't run 24/7, every time you power off you will lose all progress, since the next startup will be right back at square one. Secondly if you have any type of crash or if you get one of those "zero exit status but no finished file" situations (as one of my machines does from time to time) you will lose all progress.

People basically have three choices:-

1. Revert to the previous app and wait for Bernd to release 6.07
2. Keep the app in memory and make sure you don't lose power or crash :-).
3. Make your checkpoint file "auto-update" by user intervention.

For the third option, if you look in the slots directory where the crunching is occurring, you will immediately see that the problem is characterised by the presence of a way-out-of-date checkpoint file (.cpt extension) and a very-up-to-date temporary file (.cpt.tmp extension) that is supposed to be replacing the .cpt file every time there is a new checkpoint available to be saved. If you delete the .cpt file, the next time a new checkpoint is ready, it will be able to be written as a file since there will be nothing to block the .tmp file from being renamed to the .cpt file. I'm not suggesting that anyone do this manually. It should be possible to have a fairly simple Windows batch file do it for you automatically at regular intervals.

BTW, I have actually confirmed that deleting the out-of-date checkpoint does allow a fresh up-to-date one to be written. So now my "zero exit status but no finished file" machine is actually making some progress again. It has so far clocked up 38 hours on a task that used to take less than 19 under the old app. It has just reached 67% finished and I've just "refreshed" its checkpoint file which was 2 hours out-of-date again. Of course, I could revert to the previous app to finish it off but that would take away all the fun of getting this task "over the line". If the OS were Linux, I'd write a shell script but I've got no desire whatsoever to do the same job in Windows since I'm completely ignorant about batch files. I don't even know if Windows has a sleep command - surely it must have, I guess.

Athlon XPs were great CPUs in their day. The Thoroughbred or Barton cores overclock quite nicely too. I've got three Athlon XP hosts that have been converted to 6.06. I also have a little history on 6.04 so it should be possible to get a reasonable guesstimate for any speedup.

If your wingman's core 2 host has a largish cache, you should always easily beat him - no surprise there :-).

Without some crunching history on 6.04, how are you going to measure the approximate speedup?

He only had one task, that's why I was surprised.

I'd run a few 6.04 and then the 6.06 on the Duron. I doubt they'll need the info though. Between just what myself and especially you (since you would be running more than I can, which btw I'm interested in seeing too) as well as any others out there could return on the XP's, I'm guessing will give them what they're looking for in reults. I just thought I'd offer.

Edit:

OK, got it installed and ready to run. Will be switching tasks between the opti AP and the 6.07

I guess because he's probably running something like Seti as the main project with E@H as a very low resource share backup :-).

Ahhh... That would work nicely! As you say, there is probably not much point as there will be plenty of others who could give a faster answer.

Although I'd long ago converted the bulk of my machines to Linux, there are probably around 10 SSE machines in my fleet still running Windows that will get upgraded to 6.07. Most of these had been recently upgraded to 6.06. I'll certainly report about these once there is something significant to report.