Posts by LucaB76 - BOINC.Italy

1) Message boards : BOINC Manager : Trojan boinc installation by rogue member (Message 8325) Posted 20 Feb 2007 by LucaB76 - BOINC.Italy Post: Thanks for your post, mo.v! When the victim of the infection came to our forum, we helped in every possible way but every our effort was, at first, unsuccessful. Then we started to understand that something "unusual" was running on his notebook. So we asked him to save & send the infected directories... and we discovered the truth! An ugly trick from an irresponsible user... and he risked to lose his laptop and, most important, his work. With this post I wish to thank every projects staff member, that replied to our forum moderator, GHz, to have done every effort to stop "Wate". Let's hope that this problem won't happen again! Greetings from Italy by LucaB76 & BOINC.Italy
2) Message boards : BOINC client : Problem with the work buffer (Message 8133) Posted 10 Feb 2007 by LucaB76 - BOINC.Italy Post: Excellent! Good job, John McLeod VII! Now everything is clear and my doubts are confirmed. With some particular combination between cache & deadline, you can't reach the desidered cache. And the main reason is because "Connect to network every X days" is not a cache, but it's, obviously & exactly a parameter about connection! This is a good strategy for the daily use, but maybe could bring some problems in special event. Here I make two example: 1) Server failures: usually I keep a 3-5 days of cache to avoid problems due to server failures. Having a big cache you have a lot of work and you can wait the server's recovery, without worring about empty cache. Obviously you can avoid this problem working on two or more projects. 2) Vacations and no network available: usually I use BOINC even on my notebook that share my desktop PC's connection. But sometimes I used to fill 7 days of cache to have work even on a trip without Internet connection. When I returned home, my notebook was full of results to report (within deadline) to the projects. Unfortunately, this problem is not resolved by joining more than a project, right? Now, using your formula, you can have: about 3 days of cache on projects with 7 days of deadline; about 4 days of cache on projects with 9 days of deadline; about 5 days of cache on projects with 11 days of deadline; about 6 days of cache on projects with 13 days of deadline; about 7 days of cache on projects with 15 days of deadline; about 8 days of cache on projects with 17 days of deadline; about 9 days of cache on projects with 19 days of deadline; about 10 days of cache on projects with 21 days or more of deadline. So the upper limit for the cache is no more in the hands of the user but it's controlled by the project's deadline. Do you think that it will be possible to have two different parameters in the preferences to set cache AND network connections? In this ways we could have a big cache even with a 24/7 connection and we could be free to take our decisions! Thanks again! Luca B.
3) Message boards : BOINC Manager : Someone explains how the new scheduler works! (Message 8111) Posted 9 Feb 2007 by LucaB76 - BOINC.Italy Post: John, I'm curious about a fact: SIMAP has a deadline of 8 days since you d/l the WU. Now suppose that my cache is empty, that I've set the cache to 7 days, that my DCF is 0.6 for SIMAP, that I have no problems with debts with the project and SIMAP is the only active project (with the others set to Suspended & No New Work). I ask to you: Is it possible to fill 7 days of cache on SIMAP with the new scheduler? IMHO, using the formula you posted on Seti forum report deadline - (min_queue + project switch interval + 1 day), there is no chanche! Cause if report_deadline is 8 and min_queue is 7, the scheduler will be always in deadline problems! In theory, I shouldn't have any problems to do 7 days of work within 8 days... With the old version there were no problems to do this. Two days ago, with the new scheduler and 10 WUs waiting to run, I was unable to get more work on SIMAP. Why? Is my idea correct?
4) Message boards : BOINC Manager : Someone explains how the new scheduler works! (Message 8108) Posted 9 Feb 2007 by LucaB76 - BOINC.Italy Post: Thanks for this lesson, Ageless! But after one year on BOINC and five years on SETI Classic, I konw well the differences between daemon, manager and project's application. I used the term "Manager" just to simplify... I usually work with the client_state to tweak my debts, to force some decisions of my scheduler... or better I used to force these decisions! I opened this thread just because, with the new scheduler policy, I can't force the scheduler to do what I want. With 5.4.11 I could reset the debts and set the cache to 7.0 days to have plenty of works for SIMAP, without any deadline problem. But this is no more possible with the new version, because "the formula" (If the task will not complete by round robin simulation in < 90% of the time to the computation deadline it is in deadline trouble. The computation deadline is the report deadline - (min_queue + project switch interval + 1 day).) deny this procedure and vain every my effort to take more WUs. And there is nothing I can do about it. Than I had the accident reported in this thread. And, once again, nothing to do with this scheduler. My DCF indicated to him that I was able to do a lot of work on uFluids ('cause the last batch of WUs were extremely short) and the scheduler filled my cache with 360 result... even if now every WUs is taking hours to complete. There is no error or bug in the scheduler, now I know that I was unlucky and that I've fallen into a "limit case"! These two facts happened in two successive days and they were linked to two opposite situations. I had just changed my BOINC version and I pointed my finger to the new scheduler. Now I'm trying to cure my wounds and I'm searching a good strategy to set things in their own way. Luca B.
5) Message boards : BOINC Manager : Someone explains how the new scheduler works! (Message 8103) Posted 9 Feb 2007 by LucaB76 - BOINC.Italy Post: Thanks Ageless, but, as I stated in a previous post, I've already put at work the 5.8.9 and it has fixed the problem with DCF. If my DCF has gone so high is just because my last WUs were extremely short (10min) while the new ones are quite long (4h or more). Now the Manager is trying to set things right and my DCF is gone from 37 (after the first WU returned) to 34 (after three WUS)... thanks to 5.8.9! Luca B.
6) Message boards : BOINC Manager : Someone explains how the new scheduler works! (Message 8099) Posted 9 Feb 2007 by LucaB76 - BOINC.Italy Post: Thanks for your help, Kathryn. The uFluids WUs were built to last 2-3 minutes, then Bob increased that time to 10 minutes... so your simulation is not so far from reality! ;-) The decision made by the scheduler is, in this situation, clearly correct! But now, someone at uFluids should tell me why these WUs are taking HOURS to finish! To recapitulate... I'm only just a bit unlucky in this period... ;-) Do you think that a complete re-installation from scratch of BOINC (to erase even the client_state) and a minimum cache at 0.5 can re-establish a good order? My debts and DCF will reset and maybe the scheduler could have a bit of time (with a small cache) to sort things out! Thanks again! Luca B.
7) Message boards : BOINC Manager : Someone explains how the new scheduler works! (Message 8094) Posted 9 Feb 2007 by LucaB76 - BOINC.Italy Post: I think the reason you got so many uFluids WUs is probably related to what your DCF was (didn't they have a lot of short WUs that came with extremely high estimated time to completion which would drive your DCF down low). If you DCF was really low and the estimates by the project for how many operations the WU would take is off, then you'll download a boatload of work. I use 4 PC on BOINC; this time I opened only my PC at home for uFluids and I can't say what was my DCF before the huge download. But I can say that the other three PC have a DCF on uFluids that ranges between 0.75 and 1.25... so I suppose that even my PC at home was in the same rage. And I can say that after only 2 completed uFluids WUs my DCF is gone to 37.802176 (even with 5.8.9 that fix the problem related to DCF). Obviously the scheduler decided to download all these WUs without working on them because I still had some SIMAP WUs to crunch... D'oh! So you think that, once again, I've been unlucky... The problem is that I've never had similar accidents with 5.4.11 and my way to work with BOINC is never changed!
8) Message boards : BOINC Manager : Someone explains how the new scheduler works! (Message 8086) Posted 9 Feb 2007 by LucaB76 - BOINC.Italy Post: A few days ago I've updated my BOINC Manager with the new version 5.8.8. I was trying to have a bigger cache of SIMAP WUs (I was running only SIMAP), so I setted my "Connect to network about every" at 7days and the outcome is been... no new WUs downloaded! :-( After a lot of threads reading, I re-setted my cache to 2days and the scheduler allow me to download 10-20WUs. You can read about this adventure here. After a lot of SIMAP WUs returned, I setted my cache to 1.5day and I unsuspended uFluids and allow to get more work, then I go out. Tonight I opened my BOINC Manager and I've seen 360 WUs downloaded from the scheduler. So, I want a big cache, put 7.0days and it doesn't get new work; I want to avoid to get a lot of WUs, put 1.5days and it download work for a month and more, even if the deadline is at 15days. I'm really upset! I hate this scheduler! Maybe it takes wrong decisions when only one project is running... I don't know! PLEASE, someone explains how this new scheduler works and why it behaves in this way! I've red a lot of threads and posts, I know the rules and the formula that the scheduler uses to take a decision... but, at a first glance, it seems to do the exact opposite!! Thanks in advance for your help! Luca B.
9) Message boards : BOINC client : RDCF is still going up (Message 8048) Posted 7 Feb 2007 by LucaB76 - BOINC.Italy Post: Ageless, I've had the same problem on SIMAP: Initial RDCF: 0.680, ETC: 2h20m, RT: 1h38 for every WUs and after 15-20 WUs, Final RDCF: 0.714, ETC: 2h24m; As a bonus problem, I experienced this! Bad times for periodic projects! :-(
10) Message boards : BOINC client : Problem with the work buffer (Message 8043) Posted 6 Feb 2007 by LucaB76 - BOINC.Italy Post: If you have the feeling that your client is wrong, you can increase the amount of requested work by adding a work_request_factor to your client configuration. http://boinc.berkeley.edu/client_msgs.php I've seen that option... but it's impossible to tweak the scheduler, by debug options, on every moment, on a bunch of different systems! Sorry, but... someone gave us a new scheduler... I'm only asking that the scheduler could work in the right way!
11) Message boards : BOINC client : Problem with the work buffer (Message 8036) Posted 6 Feb 2007 by LucaB76 - BOINC.Italy Post: Reverting John's formula (while keeping in mind that John's formula has to evaluate positively in order to allow new work fetch) to report deadline - (project switch interval + 1 day) > min_queue one can calculate optimum value of connect every for Luca's project of preference to roughly 6.97 days. This is a very interesting thing, Metod. Thanks to point it out! But I've got to reduce day-by-day my cache setting until I reach 2.0 days to collect a little bunch of new WUs. Now I've setted to "No New Work" to empty my cache and clear my BOINC folder. Then, after a new installation on every single machine and a new client_state.xml, I'll set my work buffer to find the best parameter.
12) Message boards : BOINC client : Problem with the work buffer (Message 8031) Posted 6 Feb 2007 by LucaB76 - BOINC.Italy Post: Kathryn, I agree with you in one point... the scheduler works on a base of numbers: if numbers are right, everything is fine; if even a sigle number is wrong, the whole result could be a disaster. Guided by this idea I wrote my first post! I run application for BOINC since January 2006 and I'm a Seti@Home user since 2000. So I think to have a good experience on distribuited computing. And i'm taking my degree in Computer Science, so I think to know how PCs works with developpers, debuggers, linkers and so on. Before to open this thread I've tried everything I knew to solve the problem and I've made every effort to have the "right numbers", to ease my BOINC Manager's life. I'm not saying that the Manager is bugged. Now that I know how the new scheduler works (I hope), I say ok, its formula said "no" and it has made the right decision... no new work! But, IMHO, something is wrong with the formula. With 5.4.11 you ask more work by specifying a bigger work buffer. My experiences with 5.8.8 say: if you want more works... reduce your work buffer! What comes out from this story is that, even if you do your best efforts, you can't have a big cache (especially if the time allowed, 8days, is near to your work buffer setting, 7days)! Maybe cases like this were left out of consideration at the moment of the scheduler's analisys. Or maybe they were not taken into account 'cause the scheduler is not intended to work with this target.
13) Message boards : BOINC client : Problem with the work buffer (Message 8024) Posted 6 Feb 2007 by LucaB76 - BOINC.Italy Post: I've reduced the work buffer at 2.0 days and it worked! My first pc (56Wus in cache) replied: 06/02/2007 13.06.21\|boincsimap\|Sending scheduler request: Requested by user 06/02/2007 13.06.21\|boincsimap\|(not requesting new work or reporting completed tasks) 06/02/2007 13.06.26\|boincsimap\|Scheduler RPC succeeded [server version 505] 06/02/2007 13.06.26\|\|General prefs: from boincsimap (last modified 2007-02-06 13:06:05) 06/02/2007 13.06.26\|\|Host location: none 06/02/2007 13.06.26\|\|General prefs: using your defaults 06/02/2007 13.06.26\|\|[work_fetch_debug] Request work fetch: Prefs update 06/02/2007 13.06.26\|boincsimap\|Deferring communication for 7 sec 06/02/2007 13.06.26\|boincsimap\|Reason: requested by project 06/02/2007 13.06.26\|\|[work_fetch_debug] Request work fetch: RPC complete 06/02/2007 13.06.26\|\|[work_fetch_debug] compute_work_requests(): start 06/02/2007 13.06.26\|\|[work_fetch_debug] compute_work_requests(): cpu_shortfall 0.000000, overall urgency Don't need It didn't get new work but exited from the Urgency status. My second pc (just 18WUs in cache) got about 20 new WUs and replied: 2/6/2007 1:15:25 PM\|\|[work_fetch_debug] Request work fetch: timer 2/6/2007 1:15:25 PM\|\|[work_fetch_debug] compute_work_requests(): start 2/6/2007 1:15:25 PM\|\|[cpu_sched_debug] CPU efficiency old 0.996921 new 0.996908 wall 51.093750 CPU 49.828125 w 0.999409 e 0.975229 2/6/2007 1:15:25 PM\|\|[work_fetch_debug] compute_work_requests(): cpu_shortfall 0.000000, overall urgency OK So, even in this case no more Urgency! Now that every PC is in "safe mode", I still have a question: What can I do to set up a big cache (for vacancy reasons, for example)? Thanks again!
14) Message boards : BOINC client : Problem with the work buffer (Message 8023) Posted 6 Feb 2007 by LucaB76 - BOINC.Italy Post: Ok, I've tried to take a look at the formula. The original post from John McLeod VII says: The determination of when a task is in deadline trouble has also changed. [...] 5.8 uses only one criteria. If the task will not complete by round robin simulation in < 90% of the time to the computation deadline it is in deadline trouble. The computation deadline is the report deadline - (min_queue + project switch interval + 1 day). Now, I've setted a Work Buffer of 7.0 days (min_queue param.), my "Switch between applications every" is 30 minutes (30/60/24 = 0.0208 days) and SIMAP gives WUs with a 8.0 deadlines. With the old client there was nothing wrong with that and I've never missed a deadline. Instead, using the new formula, it's impossible to not overcommit the pc! Why? It's simple: the formula becomes 8.0 - (7.0 + 0.0208 + 1.0) = 8.0 - 8.0208 = -0.0208! So I have no time to complete even only one result. And this is exactly what my BOINC Manager says! So, if you set your work buffer to 7.0 days and the projects has a deadline of 8.0 days... you have no chance to get new work... It must be something wrong... Don't you think? Now it seems to me that the only way to get more work... is to reduce the work buffer... Straightforward, isn't it? :-) I'm still even more puzzled!
15) Message boards : BOINC client : Problem with the work buffer (Message 8022) Posted 6 Feb 2007 by LucaB76 - BOINC.Italy Post: Thanks for your replies, guys! This scheduler is still a mistery for me! That's why... I've got another P4 3.0GHz HTed, in the same condition of the first one. This is a shot of its current cache: Only 18 WUs! And what does the scheduler says? 2/6/2007 10:46:39 AM\|\|[work_fetch_debug] Request work fetch: timer 2/6/2007 10:46:39 AM\|\|[work_fetch_debug] compute_work_requests(): start 2/6/2007 10:46:39 AM\|\|[cpu_sched_debug] CPU efficiency old 0.996912 new 0.996898 wall 120.250000 CPU 118.703125 w 0.998609 e 0.987136 2/6/2007 10:46:39 AM\|\|[debt_debug] adjust_debts(): project boincsimap: STD 0.000000, LTD 71273.076143 2/6/2007 10:46:39 AM\|\|[debt_debug] adjust_debts(): project Einstein@Home: STD 0.000000, LTD 0.000000 2/6/2007 10:46:39 AM\|\|[debt_debug] adjust_debts(): project lhcathome: STD 0.000000, LTD 0.000000 2/6/2007 10:46:39 AM\|\|[debt_debug] adjust_debts(): project Spinhenge@home: STD 0.000000, LTD -71273.076143 2/6/2007 10:46:39 AM\|\|[debt_debug] adjust_debts(): project uFluids: STD 0.000000, LTD 0.000000 2/6/2007 10:46:39 AM\|\|[work_fetch_debug] compute_work_requests(): cpu_shortfall 1067398.264524, overall urgency Need 2/6/2007 10:46:39 AM\|boincsimap\|[work_fetch_debug] project has 18 deadline misses 2/6/2007 10:46:39 AM\|Einstein@Home\|[work_fetch_debug] work fetch: project not contactable 2/6/2007 10:46:39 AM\|lhcathome\|[work_fetch_debug] work fetch: project not contactable 2/6/2007 10:46:39 AM\|Spinhenge@home\|[work_fetch_debug] work fetch: project not contactable 2/6/2007 10:46:39 AM\|uFluids\|[work_fetch_debug] work fetch: project not contactable IMHO, every task will be completed within midnight (to stay relaxed!), so easily contained withind the deadline. Instead the scheduler detects 18 deadline misses, so EVERY WUs is, in its opinion, at risk to miss the deadline. I can't figure out how is it possible! I don't know which numebers it uses or what kind of calculation it does... The only thing I know is that I didn't cheat to get these 18 WUs, but the scheduler of version 5.4.11 decided to get them. Then I installed the new version and now the PC is overcommitted! Ok, now the criteria are more strict than before... or maybe the new version need some time to understand how things goes... Anyway... I'm still puzzled!
16) Message boards : BOINC client : Problem with the work buffer (Message 8013) Posted 6 Feb 2007 by LucaB76 - BOINC.Italy Post: I've used the new cc_config.xml with a bit of debug option and this is the outcome: 06/02/2007 3.02.23\|\|[cpu_sched_debug] Request CPU reschedule: Core client configuration 06/02/2007 3.02.23\|\|[work_fetch_debug] Request work fetch: Core client configuration 06/02/2007 3.02.23\|\|[cpu_sched_debug] schedule_cpus(): start 06/02/2007 3.02.23\|boincsimap\|[cpu_sched_debug] Project has 62 projected deadline misses 06/02/2007 3.02.23\|\|[cpu_sched_debug] CPU efficiency old 0.955769 new 0.955806 wall 98.343750 CPU 97.156250 w 0.998862 e 0.987925 06/02/2007 3.02.23\|\|[debt_debug] adjust_debts(): project boincsimap: STD 0.000000, LTD 100000.000000 06/02/2007 3.02.23\|\|[debt_debug] adjust_debts(): project Einstein@Home: STD 0.000000, LTD -100000.000000 06/02/2007 3.02.23\|\|[debt_debug] adjust_debts(): project lhcathome: STD 0.000000, LTD 0.000000 06/02/2007 3.02.23\|\|[debt_debug] adjust_debts(): project SETI@home: STD 0.000000, LTD 0.000000 06/02/2007 3.02.23\|\|[debt_debug] adjust_debts(): project Spinhenge@home: STD 0.000000, LTD 0.000000 06/02/2007 3.02.23\|\|[debt_debug] adjust_debts(): project uFluids: STD 0.000000, LTD 0.000000 06/02/2007 3.02.23\|boincsimap\|[cpu_sched_debug] earliest deadline: 1171108138.000000 70201009.015868_0 06/02/2007 3.02.23\|boincsimap\|[cpu_sched_debug] scheduling (deadline) 70201009.015868_0 06/02/2007 3.02.23\|boincsimap\|[cpu_sched_debug] earliest deadline: 1171108138.000000 70201009.015592_1 06/02/2007 3.02.23\|boincsimap\|[cpu_sched_debug] scheduling (deadline) 70201009.015592_1 06/02/2007 3.02.23\|\|[cpu_sched_debug] Request enforce CPU schedule: schedule_cpus 06/02/2007 3.02.23\|\|[cpu_sched_debug] enforce_schedule(): start 06/02/2007 3.02.23\|boincsimap\|[cpu_sched_debug] want to run: 70201009.015868_0 06/02/2007 3.02.23\|boincsimap\|[cpu_sched_debug] want to run: 70201009.015592_1 06/02/2007 3.02.23\|boincsimap\|[cpu_sched_debug] processing 70201009.015868_0 06/02/2007 3.02.23\|boincsimap\|[cpu_sched_debug] 70201009.015868_0 is already running 06/02/2007 3.02.23\|boincsimap\|[cpu_sched_debug] processing 70201009.015592_1 06/02/2007 3.02.23\|boincsimap\|[cpu_sched_debug] 70201009.015592_1 is already running 06/02/2007 3.02.23\|\|[cpu_sched_debug] finished preempt loop, nrunning 2 06/02/2007 3.02.23\|boincsimap\|[cpu_sched_debug] 70201009.015868_0 state 2 next 2 06/02/2007 3.02.23\|boincsimap\|[cpu_sched_debug] 70201009.015592_1 state 2 next 2 06/02/2007 3.02.23\|\|[cpu_sched_debug] enforce_schedule: end 06/02/2007 3.02.23\|\|[work_fetch_debug] compute_work_requests(): start 06/02/2007 3.02.23\|\|[work_fetch_debug] compute_work_requests(): cpu_shortfall 608421.810224, overall urgency Need 06/02/2007 3.02.23\|boincsimap\|[work_fetch_debug] project has 62 deadline misses 06/02/2007 3.02.23\|Einstein@Home\|[work_fetch_debug] work fetch: project not contactable 06/02/2007 3.02.23\|lhcathome\|[work_fetch_debug] work fetch: project not contactable 06/02/2007 3.02.23\|SETI@home\|[work_fetch_debug] work fetch: project not contactable 06/02/2007 3.02.23\|Spinhenge@home\|[work_fetch_debug] work fetch: project not contactable 06/02/2007 3.02.23\|uFluids\|[work_fetch_debug] work fetch: project not contactable Obviously, due to the deadline misses, the Manager doesn't ask for more work! But now the question is... Why does he detect 62 deadline misses? WUs will miss the deadline if not returned within 10/02/2007... 4 full days... so within the calculation made on the first post! Any idea? See you tomorrow... it's time to sleep...
17) Message boards : BOINC client : Problem with the work buffer (Message 8011) Posted 6 Feb 2007 by LucaB76 - BOINC.Italy Post: I've tried that road too. I stopped the client, manually changed the LTDs and this was my LTDs situation (red by Debt Viewer): PRJ: BOINCSIMAP STD: 0.000000 LTD: 100000.000000 RSRC: 1000 PRJ: EINSTEIN@H STD: 0.000000 LTD: -100000.000000 RSRC: 1 PRJ: LHCATHOME STD: 0.000000 LTD: 0.000000 RSRC: 1 PRJ: SPINHENGE@ STD: 0.000000 LTD: 0.000000 RSRC: 1 PRJ: UFLUIDS STD: 0.000000 LTD: 0.000000 RSRC: 1 I've restarted the client, I've manually updated... No effects!
18) Message boards : BOINC client : Problem with the work buffer (Message 8009) Posted 6 Feb 2007 by LucaB76 - BOINC.Italy Post: Unfortunately, this is not the case! :-( These are the messages you asked: 06/02/2007 2.10.35\|boincsimap\|Sending scheduler request: Requested by user 06/02/2007 2.10.35\|boincsimap\|(not requesting new work or reporting completed tasks) 06/02/2007 2.10.40\|boincsimap\|Scheduler RPC succeeded [server version 505] 06/02/2007 2.10.40\|boincsimap\|Deferring communication for 7 sec 06/02/2007 2.10.40\|boincsimap\|Reason: requested by project As you can see it's my lazy & guilty Manager :-) And, unfortunately again, I've got two other PC in this situation. D'oh!!
19) Message boards : BOINC client : Problem with the work buffer (Message 8007) Posted 6 Feb 2007 by LucaB76 - BOINC.Italy Post: I'm having a trouble with the last 5.8.8 scheduler. - I've set a work buffer of 7.5 days in the general preferences, to do along run on SIMAP; - I've suspended every other project on my pc (Suspended & No new task); - I've done a reset to the long term debts; - SIMAP has a resource share of 1000 and every other project has a resource share of 1; - I don't have any other project's WUs in the cache. In spite of all this... there is no way to get more work even if my work queue is shorter than setted by preferences: at the moment I've 72 WUs (2h each), but running two task at once with my P4 HTed, in 72h I can finish them, so in 3 days... Where are the other 4.5 days of cache? Why the BOINC Manager doesn't ask for more work? Let's add some details: I don't have problems with disk space, I didn't reach the "Maximum daily WU quota per CPU", there is work available on SIMAP, my pc is not overcommitted and I don't have the global_preferences_override.xml in use. Furthermore, these are my activity parameters from client_state.xml: <on_frac>0.792576</on_frac> <active_frac>0.997625</active_frac> <cpu_efficiency>0.978744</cpu_efficiency> So even if my pc is on only 19h/24, I should arrive to 7.5 * 0.792576 * 0.997625 * 0.978744 = 5.8 days... but I'm stopped at 3 days! I know that, in the new version 5.8.8, work fetching policies are changed, but I can't figure out what's happening! What can I do to obtain a bit of new work? Any help is appreciated! Thanks a lot! Luca B. from Italy

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.