Always High Priority - GRRR |
Message boards : Cruncher's Corner : Always High Priority - GRRR
| Author | Message |
|---|---|
|
Hello all, | |
| ID: 114485 | | |
Hello all, I can understand your concerns. But my Experience with e@h is vollladend different. This project is the most reliable one in considering configurations. Other projects like Milkyway@Home or actually LHC@Home are let me say, progressivly Interpretin the boing rules. The are pressing into the usual methods, causing a delay for e@h wu's. Example from today. LHC@Home wu is Running with high priority. They gave only 7days for crunching and due date is Oct 19th. For this wu a e@h LAT wu is postponed despite the fact, that it is a long runner with due date tomorrow. So the reason for e@h wu with high prio is mostly in wu from other projects. That's my experience. ____________ ![]() | |
| ID: 114486 | | |
|
You can easily adjust priority of the applications using Process Lasso. This program will maintain the priority settings. Also this program has the option to set affinity so you can bind the applications to any cores of your choosing. | |
| ID: 114488 | | |
You can easily adjust priority of the applications using Process Lasso. This program will maintain the priority settings. Also this program has the option to set affinity so you can bind the applications to any cores of your choosing. When Boinc puts tasks into High Priority, all it is doing is changing the Order the work is done, it Doesn't change any priority levels of any applications, Claggy | |
| ID: 114495 | | |
You can easily adjust priority of the applications using Process Lasso. This program will maintain the priority settings. Also this program has the option to set affinity so you can bind the applications to any cores of your choosing. in this case "high priority" is refering to EDF (earliest deadline first) mode. not process priority. if hes refering to http://einstein.phys.uwm.edu/results.php?hostid=4230718 the deadline is tomorrow 2 weeks from the date they where issued. so e@h is actually playing nice, the real question would be what other project isnt, or what is keeping him from meeting the deadline of the wu's issued. i would be interested to know how much work hes downloading for each project, how long he allows the system to run, and what those resource shares are for each project. especially given the stats for that system. ____________ seeing without seeing is something the blind learn to do, and seeing beyond vision can be a gift. | |
| ID: 114498 | | |
.... If einstein can't be a good citizen on my computer, then it won't BE on my computer. Sorry. Why do you blame Einstein for something completely beyond Einstein's control? Do you understand that the BOINC client decides what will run and when it will run and the BOINC client simply is responding to the settings you have chosen. If you choose 'difficult' settings, it's not surprising that BOINC doesn't cope. And yet you blame Einstein .... Take a look at this response I made a while ago to a very similar 'complaint' to yours. You haven't given enough details to be sure but the cause of your problems are probably very much the same as what I suggested at that time. Specifically, if a particular project in your mix can't supply work, BOINC will tend to fill your work cache with tasks from a project that can. If you have a large cache size and a low resource share for the poor project that ends up filling your cache, the problem you describe is pretty much bound to happen. Perhaps you could stop BOINC downloading excessive E@H work and then having to resort to panic mode to clear the backlog if you reduced your work cache size a bit. If you'd like suggestions on how to work around BOINC's limitations, let us know what settings you are currently using. It should be possible to very much reduce BOINC's use of panic mode. ____________ Cheers, Gary. | |
| ID: 114534 | | |
Message boards :
Cruncher's Corner :
Always High Priority - GRRR