Message boards : Questions and problems : BOINC marked SETI as "overworked" and doesnt fulfill queue cache requirements
Message board moderation
Author | Message |
---|---|
Send message Joined: 9 Apr 06 Posts: 302 |
Project shares: SETI 10 000 MW 6 000 Einstein 10 SETI beta 100 After clearing all debts for all projects ~week ago SETI build up LTD of -755 000 s and marked as "overworked". Most time only SETI and MW active. Why SETI has so big LTD ? And why BOINC refuse to ask any work from SETI while cache ( 0.1+4 days ) hardly have one day of work now... Also, MW tends to run in high priority and build up positive STD permanently while its project share lower than SETI's one. What is wrong with BOINC scheduler? ( 6.6.20 ) |
![]() Send message Joined: 29 Aug 05 Posts: 15632 ![]() |
I just learned that the <on_frac> value has been disabled since February 2009... this affects all 6.6 versions, probably all 6.8 versions and definitely 6.10.1, 6.10.2 and 6.10.3. And it will affect the long term debt as your BOINC will think the computer's been off since February 2009.... 6.10.4 has a fix. You then just need to update your <on_frac> by hand to something above what it is now and probably resembling 0.999999. ;-) |
Send message Joined: 9 Apr 06 Posts: 302 |
I just learned that the <on_frac> value has been disabled since February 2009... this affects all 6.6 versions, probably all 6.8 versions and definitely 6.10.1, 6.10.2 and 6.10.3. And it will affect the long term debt as your BOINC will think the computer's been off since February 2009.... OMG... it could affect those problems with "will not completed in time" that caused so many troubles in 6.6.36... |
Send message Joined: 9 Apr 06 Posts: 302 |
BTW, how STD calculates now? For example if one project has share X and run 4 instances of app simultaneously and second project has share Y and runs 24 (MW ;) ) apps simultaneously - what project STD should increase ? Also, will STD depend from max/avg_cpu value used in app_info or only elapsed times measured by BOINC matters ? |
![]() Send message Joined: 29 Aug 05 Posts: 15632 ![]() |
I am not quite sure what changed in the effect of STD. it was difficult to follow before the change of debts, it was even more difficult to follow afterwards. ;-) But I'll try to get JM7 over here to give an in depth answer. |
![]() Send message Joined: 29 Aug 05 Posts: 147 |
The basic calculation of STD has not changed - ifyour computer does not use a GPU. (More on that later). The major difference is that all STD values are non-positive. If something changes the STD of a project to be positive, all of the STD values for active projects are shifted so tat the maximum STD is 0. Active projects do not include NNW with no tasks, suspended, or projects at max deferral - unless it has been too long since the project was asked for work. Projects that are not active and not overworked will not have their STDs change. ** I am not certain of the state of STD versus GPUs. I do know that there was a problem with STD values for projects with GPU usage would go to negative infinity. ![]() BOINC WIKI |
Send message Joined: 9 Apr 06 Posts: 302 |
From What BOINC version this STD "non-positive" rule enforced? With BOINC 6.6.20 I see very big positive along with very big negative STDs on different projects. I use BOINCView for observations but when I look into client_state I see same numbers so think BOINCview still working correct. But it seems your description applied to LTD (long term debt). MW has its LTD at zero, all other projects have negative LTD. But still not understand from where numbers like -775 kilo seconds come... This number roughly corresponds to total BOINC up time from last debts correction. Why it thinks it should not download any work for project with biggest share among all others? |
![]() Send message Joined: 8 Jan 06 Posts: 448 ![]() |
Deleted. my mistake. |
Copyright © 2025 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.