|
1)
Message boards :
BOINC Manager :
Developers request help on finding errors
(Message 5391)
Posted 20 Aug 2006 by tralala Post: Robert it's off-topic here but two remarks: 1. You should add climateprediction only in the case you are a) crunching 24/7 or at least 12 hours per day and give it a fair ressource share (at least 33%). Their WU take 4 month with 24/7 hour crunching and won't finish in time if you crunch them less than 4-6 hours per day on average. 2. You should set "Leave application in memory while preempted" to "Yes". You can do this in your general preferences. That way you don't loose work while switching between projects. |
|
2)
Message boards :
BOINC client :
Windows XP x64
(Message 4666)
Posted 7 Jun 2006 by tralala Post: Hi, I did a keyword search but found no posts concerning x64. I'm sure this issue has been raised but here I'm reraising it? When can we expect 64bit support for Windows XP x64? |
|
3)
Message boards :
BOINC client :
Per Processor Scheduling
(Message 4004)
Posted 21 Apr 2006 by tralala Post: Another solution to this problem is proposed here: http://boinc.berkeley.edu/dev/forum_thread.php?id=739 but for some reason the idea seems not to be too popular (or hard to implement). |
|
4)
Message boards :
BOINC client :
Finish WU before reschedule
(Message 3903)
Posted 15 Apr 2006 by tralala Post: Rosetta for example has nowadays big WU which can't checkpoint within an hour which will be started over and over indefinitely if "Leave app in memory" is not checked. No problem for me, I take care of all my projects/task. But a big problem for the majority of users who use BOINC with default settings and unattended and a big waste of valueable computing time for the science. |
|
5)
Message boards :
BOINC client :
Finish WU before reschedule
(Message 3892)
Posted 14 Apr 2006 by tralala Post: JM7 is already on this. The first try did not work correctly and had to be backed out but I'm sure we will get this improvement eventually. Well it seems it didn't make it into 5.4.X at least it is not listed in the version history. Switching only on checkpoints could save a lot of wasted computer time. It's no longer a problem of alpha-project. Rosetta for example has nowadays big WU which can't checkpoint within an hour which will be started over and over indefinitely if "Leave app in memory" is not checked. |
|
6)
Message boards :
BOINC client :
req: pls. revise the credits system
(Message 3859)
Posted 11 Apr 2006 by tralala Post: An optimised app should claim less credit than a normal app since your computer did less work to complete the task. A strange definition of work is that. If I can build 10 houses in a month and another person can build only 5 did I less work in that month? An optimized client should of course claim more credit than a normal app since it does more WU in the same time as the normal app. But the problem with the current system is that credit is not claimed on completed work but on timexbenchmark and that opens all possibilities of cheating (look at the Rosetta-computer-toplist). |
|
7)
Message boards :
BOINC client :
earliest deadline first scheduling
(Message 3858)
Posted 11 Apr 2006 by tralala Post: You may also try to set CPDN to no new work but to a higher share (99%). This will cause CPDN to hardly ever get suspended but will also force BOINC to download only Seti-WUs if the cache is empty. |
|
8)
Message boards :
BOINC client :
'Use no more than' preference change request
(Message 3857)
Posted 11 Apr 2006 by tralala Post: I do not know about science apps which perform better with longer "Write to disk intervalls". For some they are hardcoded (climateprediction for example) for other s they vary according to the WU (Rosetta for example). Longer "write to disk" periods can reduce hard disk stress but that is hardly of any importance. |
|
9)
Message boards :
BOINC Manager :
Feature Wish: Display current actual share ratio to user
(Message 3812)
Posted 9 Apr 2006 by tralala Post: Hi, Feature specification Let the BOINC Manager display the actual share ratio and the differences (debts or credit) to the specified share ratio for all projects. Benefits The user would see the actual share ratio and would better understand why BOINC makes its decision which project to run. It would enable him to better micromanage the shareratio he wants to obtain in the future by knowing based upon which data BOINC makes its decision. Argumentation There is a lot of confusion when it comes to the share ratio as specified by the user and the behaviour of BOINC when certain projects have long WUs/short deadlines/longer periods of no work. BOINC averages out everything in the long run but how BOINC makes its decision is not transparent to the user. Therefore there are many posts about why BOINC switched from one project to another and how to make BOINC behave like one wants to. |
|
10)
Message boards :
BOINC client :
Finish WU before reschedule
(Message 3801)
Posted 8 Apr 2006 by tralala Post: Or the other way around: project science applications should be making checkpoints regularly. There's even a setting which could be used to indicate the frequency of checkpoints (if feasible for the given project): Write to disk at most every. AFAIK for the Seasonal Attribution Project from cpdn there is no feasible way to increase the number of checkpoints. The climate model they're using is checkpointed every model day which takes in case of the high resolution model used for the seasonan project quite long. Rewriting the model to checkpoint every hour is beyond the financial and personal ressources of this project. They use as input already developed climate models and tune them for PCs. These climate models are highly complex and it is already a huge task to convert them for PCs. Changing the model itself would only lead to greater instability. It requires several years and dozens of scientists/programmers to write a climate model from scratch. Science is too complex that you can always checkpoint in all applications at convenient time intervals. Furthermore even with a checkpoint every 10 minutes one might loose up to 10 minutes per hour given the current default switching time. That's about 16%. What a waste! The best solution would be to switch only at checkpoints and only if the time to completion for the current WU is > 1 hour. P.S.: I totally agree with you that I wonder how inefficient some apps are. The speedup in Einstein is really unbelievable and lets one doubt if there was an effort put in optimizations in the first place. It seems the attitude is since BOINC-computers are for free there is no need to really bother optimizing the science apps. :-( However BOINC itself should operate as optimal as possible hence the suggestion to switch only on checkpoints and not if the WU is almost finished. |
|
11)
Message boards :
BOINC client :
Finish WU before reschedule
(Message 3781)
Posted 6 Apr 2006 by tralala Post: I think it is really urgent to allow switching of WU only after a checkpoint has been reached. As others pointed out mfluids for example has no checkpoints at the moment and attribution.cpdn.org has a checkpoint only between an hour and several hours. It also consumes about 500 MB RAM. Loosing work of several hours and paging in and out 500 MB is annoying and unnecessary if you allow switching only after reaching a checkpoint (and then safely exit the application). Furthermore an option would be nice to allow switching only after the completion of a WU. It would give the user more control what BOINC does and minimize any risk of loosing work due to switching. |
Copyright © 2024 University of California.
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License,
Version 1.2 or any later version published by the Free Software Foundation.