Well, I always allow BOINC to run when the PC is in use. When it\'s just office, server administration or surfing, BOINC gets more than 90% CPU power most of the time, except for \"peaks\" when I load a program or download a file or so- and even most games don\'t take more than about 70% CPU power on this machine (well, Guild Wars does, but I\'ve got some older games here which don\'t), so that would be a big waste imho. I know some people wouldn\'t suggest that because of the danger of crashing WUs, but I can remember only one occasion when gaming resulted in 2 crashed WUs (and that was because a driver conflict forced a freeze and reboot, thereby damaging the BOINC data on my HDD). If I compare that to all the hours of CPU time I gain when I\'m for example working for Uni, at my server or playing a game, I can\'t help but think it\'s worth the risk. I lost maybe 3 or 4 hours of CPU time in that crash- I get that back letting BOINC run during writing one piece of homework or so. Of course, with CPDN where the WUs are considerably larger, I cut down the risk by backing up after every trickle.
As for the \"writing WUs to virtual memory\"... I\'ll just trust my hard disk to do that quickly- guess it does, because I don\'t notice a lag (it better does, was expensive enough ;-) ) so I think I\'ll stick with the recommended hourly switch.
As for BOINC waiting for the WUs to reach a checkpoint- are you sure about that? It seems unlikely to me, because the switches occur exactly after one hour. I\'ve never seen them be more than 2 seconds earlier or later, which can\'t possibly be enough for any project to reach a checkpoint...

My 3.2GHz P4 is checkpointing at about 30 minutes. I haven\'t timed it with a watch while watching the HDD light, just the countdown timer, and a look at the clock.

The BOINC version where it waits for the checkpoint before switching, is the one still being tested, which will probably be released as 5.8.n
Unless there\'s another major re-think, which is what happened to the abandoned 5.6.n

As for the \"writing WUs to virtual memory\"... I\'ll just trust my hard disk to do that quickly- guess it does, because I don\'t notice a lag (it better does, was expensive enough ;-) ) so I think I\'ll stick with the recommended hourly switch.
As for BOINC waiting for the WUs to reach a checkpoint- are you sure about that? It seems unlikely to me, because the switches occur exactly after one hour. I\'ve never seen them be more than 2 seconds earlier or later, which can\'t possibly be enough for any project to reach a checkpoint...

If it\'s switching at exactly the time set in your preferences (+/- a few seconds) then that\'s proof your BOINC version does not wait for checkpoint before switching projects. In that case it\'s important to leave in memory else you\'ll be starting back at the last checkpoint and repeating work unnecessarily.

Anyway, it sounds like you have it figured out so I\'ll shut up now and wish you luck eliminating the possible 10% inefficiency.

---

Thanks :-) I\'ll wait for the trickle server to come back up and then I\'ll see if my newer results are already a bit faster.

At this point in my testing, I\'d have to conclude that the Naughty Intel patch actually hinders the efficiency of the executable.



The daily average RAC declined much more rapidly than the vanilla app after applying Naughty Intel.

In contrast, changing the app run time in BOINC from the default (and recommended) 60 minutes to 360 minutes resulted in a remarkable improvement in CPDN RAC.

---

Of course, changing the \"Switch between applications time\" is only applicable if you\'re running more than one project on your workstation. You should apply this change on each BOINC Project\'s website.

I\'m running BOINC 5.4.9 which is evidently switching between apps before checkpoints are reached. I just didn\'t realize how much work was being thrown away when the applications switched!

---

You can avoid the time loss if you set \"Leave app in memory\" to yes.
THEN if the memory is needed for something else, the data is swappped to virtual memory, instead of being dumped.

Only the BOINC version currently being tested waits until a checkpoint is reached before switching.
(And perhaps the abandoned 5.6.*)

At this point in my testing, I\'d have to conclude that the Naughty Intel patch actually hinders the efficiency of the executable.

That RAC change may be because the trickle (and therefore credit) process on the server was down for 3.x days while you were testing. The link shows one host of mine had how it had zero credits for more than 3 days while sending 4 trickles in per day, then a huge dump in credits when the process on the server came back up, which would pretty much correspond with your rapid increase in RAC.

http://www.boincstats.com/stats/host_graph.php?pr=cpdn&id=491207

Yep, my graphs look odd, too, and I didn\'t change anything about my client. In BOINCStats it is shown that I got no credits for three days and then a whole bunch at once- which is of course what one would expect after that server outage. So, Alphax, are you sure that doesn\'t influence your results?

\"Doh! Stupid reality...\"

---

Somehow, after changing my preferences, my trickles seem to have become slower, not faster! Can anyone help? Do WUs tend to become \"slower\" when you advance further, or ist it normal that some timesteps simply need more computing time than others, or is anything seriously wrong here?

There\'s a slight slowing down effect when the data files get fragmented. What I do is that when I\'ve shut down the model to do a backup, I run defrag as well, just to tidy up the files and speed things up again. I do this about weekly.

---

I'm a volunteer and my views are my own.
News and Announcements and FAQ

Defrag... God, I\'m beginning to hate Windoze, especially with my little laptop running so nicely under Debian. Well, thanks anyway for your advice :-) it is very much appreciated; I\'ll certainly try it out.

Somehow, after changing my preferences, my trickles seem to have become slower, not faster! Can anyone help? Do WUs tend to become \"slower\" when you advance further, or ist it normal that some timesteps simply need more computing time than others, or is anything seriously wrong here?

Did you synchronize BOINC with your preferences? Bring up BOINC Manager, go to the Projects tab, highlight climateprediction.net, then in the Commands box on the left, press the Update button. This will get your preferences to actually take effect on your workstation. Be sure to do the same with that other BOINC project you\'re crunching.

I think some gradual slowness over time is natural, whether it\'s from file fragmentation like MikeMarsUK says or increasing complexity in the model as time passes.

But increasing my \"switch between apps time\" to 6, then 12 hours seems to be the only method to have boosted my RAC so far. My host\'s daily RAC average has hovered at that peak at the end of the graph above.

---

Don\'t worry, I didn\'t forget to update my preferences. I\'m new to CPDN but not to BOINC. Besides, the messages tab always states sth like this:
2006-11-29 21:37:34 [climateprediction.net] Pausing task hadcm3ohc_0b9p_05562964_0 (left in memory)
So that shouldn\'t be the problem. But I seriously consider changing my intervall to a longer time...

There\'s a slight slowing down effect when the data files get fragmented. What I do is that when I\'ve shut down the model to do a backup, I run defrag as well, just to tidy up the files and speed things up again. I do this about weekly.

How much speedup have you seen after your defrag?
I\'ve just defragged my files (around 300+ fragments each) so let\'s compare notes!

---

Does the normal Windows defrag do any good or should I try and get myself sth more efficient?

It\'s OK, works best if you happen to have Boinc on its own partition (in that case it takes seconds to run rather than 15-20 minutes).

---

I'm a volunteer and my views are my own.
News and Announcements and FAQ

No, never thought of that. To be honest, I didn\'t feel very comfortable with a RAID system when I set up Windows so I didn\'t feel like playing around with partitions like that... but 15-20 minutes are okay ;-)

Okay, my unscientific little experiment has ended.
I\'ve officially concluded that on a workstation running multiple BOINC applications, including CPDN, increasing the amount of time between application switches improves CPDN\'s productivity significantly over the default settings.

Here\'s my CPDN RAC graph after my changes. I have achieved a CPDN RAC of around 400 with an application switch time of 360 minutes (6 hours). My RAC hovered around 340 when my application switch time was the default of 60 minutes (1 hour).

2 days ago on December 10th, I changed my application switch time to 720 minutes (12 hours) I\'ll report again in another week, but early results look promising.

My application of the Naughty Intel patch coincided with a CPDN server outage, so I have no conclusive evidence that the patch helped or hurt my workstation\'s productivity.

---