Index | Recent Threads | Unanswered Threads | Who's Active | Guidelines | Search |
![]() |
World Community Grid Forums
![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() |
No member browsing this thread |
Thread Status: Active Total posts in this thread: 2
|
![]() |
Author |
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
Hello everyone,
we know, that BOIC calculates the amount of free disk space and shows it in a pie chart in the last (sixth) tab to the right when advanced view is switched on. The information, how much disk space is available for BOINC is really important. If there is too little disk space available for BOINC, then results cannot be returned to the server correctly and BOINC displays calculation errors. It is not the best solution, that BOINC does not check whether there is enough disk space before !!! starting to process the workunits, It even starts new workunits, if the last one has been returned to the server incorrectly due to lack of harddisk space.BOINC will not check before starting a new workunit, whether or not there is enoough diskspace for the workunit it starts to process. It would be helpful, if BOINC took the amount of diskspace available into account during CPU benchmark. The CPU benchmark would be a CPU and harddiskspace benchmark, then. If there is not enough diskspace available for BOINC, a warning should be displayed during CPU benchmark: "Information: You have got only xy MB available for BOINC. You will not be able to take part in the following projects. a b c d etc. BOINC has found out, that you actually have more diskspace available. Please consider allowing BOINC to use it, if you want to take part in those projects" This would avoid the frustration of having claculated x hours resulting in an error. Thank you for considering my proposition. Yours Martin Schnellinger |
||
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
No idea how one could ''benchmark'' ** available ram/diskspace at peak requirement? BOINC has no clue what the tasks specify... it only knows whats allowed to be used and what it can use, which is shown in the start-up message log. The momentary requirement is constantly checked and tasks are paused when not fitting, so tasks failing due lack of disk-space prior to completion or at reporting time is ... a bug. It would help us if you give an outline of the set-up and the sequence of events of seeing these fails and what science.
The servers check if there is enough *free* RAM when work requests are made to process one such unit. They also check *free* space when requesting work as specified on the System Requirement page. The servers do *not* check if you are going to run XYZ copies concurrently or if the swap file can grow big enough to house XYZ concurrent processes plus whatever else a user is doing at the same time. Disk-space/RAM is a volatile commodity which you can set maxima for and if such are specified too tight... You can change settings at a moments notice, so should that then initiate a benchmark, which if the user is running with LAIM off, will instantly unload the science apps? *** ** The latest clients only benchmark at time of start, and only if 5 days have expired since last test, else, long as the machine/client is not stopped it will not do one anymore. *** Not sure, but think that with latest clients the benchmark holds the running tasks in memory. Then they're only unloaded at checkpoints saves, switching tasks. Assorted thoughts, don't know what could be the solution to your observed problem. I'd much rather had the developers focus on the heartbeat and zero status issues. They are the main fail for all I know. --//-- |
||
|
|
![]() |