Message boards :
Number crunching :
4.25 has been replaced by 4.43 as the "recommended" Core Client.
Message board moderation
Previous · 1 · 2 · 3
Author | Message |
---|---|
Aurora Borealis Send message Joined: 14 Jan 01 Posts: 3075 Credit: 5,631,463 RAC: 0 |
I've installed 4.43 on three computers with no problems noted so far except the Statistics Tab. Anyone else having a problem getting the stats to show up? If your upgrading from a non-stat version, it takes several updates of the projects before stats show up. Boinc V7.2.42 Win7 i5 3.33G 4GB, GTX470 |
Fred G Send message Joined: 17 May 99 Posts: 185 Credit: 24,109,481 RAC: 0 |
If your upgrading from a non-stat version, it takes several updates of the projects before stats show up. Thanks for the reply. I thought that might be the case, however I found an xml file "statistics_setiathome.berkeley.edu.xml" that I thought was for the statistics tab. I doubt installing 4.43 to another drive other than C: would cause any problems. I'll give it a couple days to see if it will work or not. Thanks again! http://www.teamstarfire.org/ |
John McLeod VII Send message Joined: 15 Jul 99 Posts: 24806 Credit: 790,712 RAC: 0 |
If your upgrading from a non-stat version, it takes several updates of the projects before stats show up. Each project must connect once one each of three separate days in order for the stats for that project to start showing. BOINC WIKI |
Ken Phillips m0mcw Send message Joined: 2 Feb 00 Posts: 267 Credit: 415,678 RAC: 0 |
Cheers John, FYI (if it works) the link below should get you my complete message file from the time of the update to my present time (21:17 UTC) John, I've emailed you, I just hadn't set the file up properly on my webserver, thanks for your patience. Ken Ken Phillips BOINC question? Look here "The beginning is the most important part of the work." - Plato |
John McLeod VII Send message Joined: 15 Jul 99 Posts: 24806 Credit: 790,712 RAC: 0 |
Cheers John, FYI (if it works) the link below should get you my complete message file from the time of the update to my present time (21:17 UTC) OK, I looked at the log, and it looks as if the CPDN WU was downloaded in response to a failed attempt to download a WU from another project. I will look at this code to see if I can find the problem. If I recall, this code is a bit different than the call where the timer initiates the download, and I was worried about it when I saw it, apparently rightly so. BOINC WIKI |
Daykay Send message Joined: 18 Dec 00 Posts: 647 Credit: 739,559 RAC: 0 |
Cheers John, FYI (if it works) the link below should get you my complete message file from the time of the update to my present time (21:17 UTC) I just had a quick look through the log and was curious about this: 22/05/2005 13:36:14||Computer is overcommitted 22/05/2005 13:36:14||Nearly overcommitted. 22/05/2005 13:36:14||New work fetch policy: no work fetch allowed. 22/05/2005 13:36:14||New CPU scheduler policy: earliest deadline first. 22/05/2005 15:06:08||schedule_cpus: time 5400.093750 22/05/2005 15:06:08||New work fetch policy: work fetch allowed. 22/05/2005 15:06:08||New CPU scheduler policy: highest debt first. Nothing changes except the schedulers evaluation of the situation. No WU's were completed in this time. Kolch - Crunching for the BOINC@Australia team since July 2004. Search for your own intelligence... |
John McLeod VII Send message Joined: 15 Jul 99 Posts: 24806 Credit: 790,712 RAC: 0 |
[quote22/05/2005 13:36:14||Computer is overcommitted 22/05/2005 13:36:14||Nearly overcommitted. 22/05/2005 13:36:14||New work fetch policy: no work fetch allowed. 22/05/2005 13:36:14||New CPU scheduler policy: earliest deadline first. 22/05/2005 15:06:08||schedule_cpus: time 5400.093750 22/05/2005 15:06:08||New work fetch policy: work fetch allowed. 22/05/2005 15:06:08||New CPU scheduler policy: highest debt first. Nothing changes except the schedulers evaluation of the situation. No WU's were completed in this time. [/quote] After crunching for an hour and a half, the result has progressed further than originally anticipated, and the emergency is off for a while. I watched a Shh unit and a CPDN unit trade 80% 20% like this for a couple of weeks. The Shh result was indeed running into time trouble, but if it got 100% of the time for 4 hours, it would think that it was a bit ahead and it would allow the CPDN uint in for an hour after which the shh unit would enter panic mode again. Every time that the CPU scheduler runs, it looks at the situation right now, and selects the mode for the next time slot. BOINC WIKI |
Daykay Send message Joined: 18 Dec 00 Posts: 647 Credit: 739,559 RAC: 0 |
OK well explained thanks John. I can see that that is a better way of doing things rather than running the Shh WU flat out to completion which would then need the scheduler to run the CPDN WU flat out later to match resource share. Kolch - Crunching for the BOINC@Australia team since July 2004. Search for your own intelligence... |
Daykay Send message Joined: 18 Dec 00 Posts: 647 Credit: 739,559 RAC: 0 |
Haha...Just found the following message in my client: 23/05/2005 12:58:17 PM|SETI@home|Requesting 3.18 seconds of work The result? Downloaded a new SETI WU. Nice one. Kolch - Crunching for the BOINC@Australia team since July 2004. Search for your own intelligence... |
EclipseHA Send message Joined: 28 Jul 99 Posts: 1018 Credit: 530,719 RAC: 0 |
Haha...Just found the following message in my client: That is EXACTLY the type of thing that should have been fixed, prior to a re-write of the scheduler. (It's been a bug since the beta 18 months ago). The client requests 3.18 seconds of work, and the server happily sends a WU with an estimated completion of 10 hours! Why doesn't the server simply respond to a request for 3.18 seconds of work with "no work available"? (unless it has some WU's that will take less than 3.18 seconds!) |
wilsen Send message Joined: 15 Apr 00 Posts: 68 Credit: 73,527 RAC: 0 |
Haha...Just found the following message in my client: What's wrong with that? At the time the clients scheduler needs work, so it requests and gets work and can happily crunch away the next 10 hours. It's not that the client gets more than one workunit - that would be a bug.
Why shouldn't the client be allowed to fill its buffer? KEINE PANIK |
Daykay Send message Joined: 18 Dec 00 Posts: 647 Credit: 739,559 RAC: 0 |
Sebastian admit that a request for 3.18 seconds of work is fairly pointless. It took longer than that to download the WU. What is the average time to completion of a SETI WU? Who knows. I can tell you though that the WU that was downloaded to fill that request took 9538 seconds to complete. A short WU, but still that is almost 3000 times longer than the amount of work that was requested. Taking a crazy logic problem further, why bother requesting work to the tenth or hundredth of a second? My point is this is just odd behaviour and should be avoided. Kolch - Crunching for the BOINC@Australia team since July 2004. Search for your own intelligence... |
wilsen Send message Joined: 15 Apr 00 Posts: 68 Credit: 73,527 RAC: 0 |
Sebastian admit that a request for 3.18 seconds of work is fairly pointless. But where is the point of waiting 9500 seconds and then do the stuff that could already be done 9500 seconds ago? KEINE PANIK |
Herk Send message Joined: 3 Apr 99 Posts: 5 Credit: 4,780 RAC: 0 |
Each project must connect once one each of three separate days in order for the stats for that project to start showing. Perhaps this should be stated on the statistics tab? |
Astro Send message Joined: 16 Apr 02 Posts: 8026 Credit: 600,015 RAC: 0 |
@kolch, I'd be worried about this only if the estimated time to completion was actually shorter than the real crunch time, but I have yet to see that be the case. I think you should be happy you snuck an extra WU out of the new scheduler. LOL |
John McLeod VII Send message Joined: 15 Jul 99 Posts: 24806 Credit: 790,712 RAC: 0 |
Haha...Just found the following message in my client: No, this behavour is quite correct. Think of CPDN and WUs that take a couple of months to process, now, think of Einstein with 7 day deadlines. Now try to make a queue size that fits both with your scheme -- not possible. So WUs that over fill the request are downloaded (but only by less than one WU). Yes, reporting the work request to the hundredth of a second does seem a bit odd, but it also doesn't hurt anything. BOINC WIKI |
Daykay Send message Joined: 18 Dec 00 Posts: 647 Credit: 739,559 RAC: 0 |
OK so next time when the client requests a couple of seconds work from CPDN and I get a new WU I should be happy? Not that my client is going to do that soon as it is not currently allowed to add to the 2 CPDN WU's that are keeping both CPU's busy. Kolch - Crunching for the BOINC@Australia team since July 2004. Search for your own intelligence... |
John McLeod VII Send message Joined: 15 Jul 99 Posts: 24806 Credit: 790,712 RAC: 0 |
OK so next time when the client requests a couple of seconds work from CPDN and I get a new WU I should be happy? Not that my client is going to do that soon as it is not currently allowed to add to the 2 CPDN WU's that are keeping both CPU's busy. When you need the WU, yes. Do you really want a queue that is 2 months large to fit the CPDN WU? BOINC WIKI |
Mistral Send message Joined: 14 Oct 04 Posts: 5 Credit: 12,600 RAC: 0 |
[/quote] I need to check what was actually built into 4.43, this should not be happening. The only times that a second CPDN WU should be downloaded are: 1) An idle CPU. 2) If the CPDN WU that you have is nearly completed.[/quote] Hi John (McLeod), I experience the same difficulty as Ken Phillips. My computer is quite slow (PIII 1 GHz). When I upgraded from 4.13 to 4.42 (end of last week) it downloaded a second CPDN workunit, even though the 1st one was around 50% of completion (i.e. around 800 CPU hours left). I aborted this second CPDN WU and went back to 4.25 until I read your posts about how 4.4x manages the swap between the various projects (I am running Seti, CPDN, Einstein and Predictor = 4 x 100, Alife, BURP and Pirates = 3 x 20). So I installed 4.43 and after a few hours the CPDN WU crashed with an error code I forgot to note. Boinc Manager then downloaded 2 CPDN WUs (in addition to 8 ghost WUs which appear only on the CPDN results page) on May 23 (yesterday), respectively at 15:41:47 and 15:41:52. Two hours ago my long term debts amounted to: - Alife@Home: -4,219 - BURP: -39,942 - ClimatePrediction: +24,862 - Einstein@Home: +6,173 - Pirates@Home: -18,475 (which seems strange to me since I never processed any Pirates WU under 4.4x and very few under 4.13) - Predictor@Home: +31,454 (I can't download any WU, in spite of 8 ghost WUs listed on my results page) - Seti@Home: +416 Preferences are set to remove from memory and to connect every 0.1 day (SDSL connection) Regards |
John McLeod VII Send message Joined: 15 Jul 99 Posts: 24806 Credit: 790,712 RAC: 0 |
I need to check what was actually built into 4.43, this should not be happening. The only times that a second CPDN WU should be downloaded are: 1) An idle CPU. 2) If the CPDN WU that you have is nearly completed.[/quote] Hi John (McLeod), I experience the same difficulty as Ken Phillips. My computer is quite slow (PIII 1 GHz). When I upgraded from 4.13 to 4.42 (end of last week) it downloaded a second CPDN workunit, even though the 1st one was around 50% of completion (i.e. around 800 CPU hours left). I aborted this second CPDN WU and went back to 4.25 until I read your posts about how 4.4x manages the swap between the various projects (I am running Seti, CPDN, Einstein and Predictor = 4 x 100, Alife, BURP and Pirates = 3 x 20). So I installed 4.43 and after a few hours the CPDN WU crashed with an error code I forgot to note. Boinc Manager then downloaded 2 CPDN WUs (in addition to 8 ghost WUs which appear only on the CPDN results page) on May 23 (yesterday), respectively at 15:41:47 and 15:41:52. Two hours ago my long term debts amounted to: - Alife@Home: -4,219 - BURP: -39,942 - ClimatePrediction: +24,862 - Einstein@Home: +6,173 - Pirates@Home: -18,475 (which seems strange to me since I never processed any Pirates WU under 4.4x and very few under 4.13) - Predictor@Home: +31,454 (I can't download any WU, in spite of 8 ghost WUs listed on my results page) - Seti@Home: +416 Preferences are set to remove from memory and to connect every 0.1 day (SDSL connection) Regards[/quote] I believe that I have found the cause of the extra WUs being downloaded. For the first few seconds of a run the estimated time to complete is 0 rather than the original estiamte, and the download policy thinks that the project is completely out of work. The fix is that until the % complete moves from 0 the original estimate is used. Should be fixed in 4.44. BOINC WIKI |
©2024 University of California
SETI@home and Astropulse are funded by grants from the National Science Foundation, NASA, and donations from SETI@home volunteers. AstroPulse is funded in part by the NSF through grant AST-0307956.