Message boards :
Number crunching :
Seti 4.07 AND 4.08 reach 100% dont and keep on calculating...
Message board moderation
Author | Message |
---|---|
taltamir Send message Joined: 30 Jul 99 Posts: 96 Credit: 51,791 RAC: 0 |
I have boinc 4.13 On the last several work units, both before and after the transition from 4.07 to 4.08. I had been getting a work unit to 100% (usually after 2 hours) and then it keeps running for a few more hours... I can see graphics for it.. and if i turn off boinc and turn it back on it resumes it normally. So i am lead to beleive it jsut doesnt estimate the time right. I thought it might be because I was compressing alot of files (winrar.. very CPU intensive)... it might have something to do with it.. but while compressing the "time remaining" remains still and the time elpased continues to tick, (which shows seti makes true on its promise of not taking ANY system resources from other software, only using unused resources). When I finish raring files the time remaining advances at the same rate as the time elpased... yet it always goes to 100% and then keeps on running. I do not have a superman complex; for I am God, not superman! |
Darrell Send message Joined: 14 Mar 03 Posts: 267 Credit: 1,418,681 RAC: 0 |
This has been a trait of the seti app on boinc since its creation. It reports itself as 100% done when the drift rate is around -47. Since the actual completion of the unit is at -50, finishing that last 3Hz/sec can very from a few minutes to a few hours depending upon the angle of the unit. |
taltamir Send message Joined: 30 Jul 99 Posts: 96 Credit: 51,791 RAC: 0 |
wow, I can't beleive I just now noticed it... And that it has yet to have been fixed! Maybe i noticed it before and forgot... I do not have a superman complex; for I am God, not superman! |
JAF Send message Joined: 9 Aug 00 Posts: 289 Credit: 168,721 RAC: 0 |
I watched a few WU's keep crunching after they reach 100%, but haven't seen any that take more than a minute or two to complete. Has anyone else seen "a few hours to completion" after reaching 100%? Since I use dial-up and disable network access, I rarely see the transition to 100%, except when I notice a WU is 98 -99%, then I stay connected and let it transfer. <img src='http://www.boincsynergy.com/images/stats/comb-912.jpg'> |
taltamir Send message Joined: 30 Jul 99 Posts: 96 Credit: 51,791 RAC: 0 |
maybe it has to do with the CPU usage.. with me compressing giant files, or recompressing hundreds of files using a convert option in winrar... and it being on absolute maximum setting ofcourse.... I do not have a superman complex; for I am God, not superman! |
The Psychotic One Send message Joined: 22 May 00 Posts: 50 Credit: 4,099,029 RAC: 0 |
I have an Athlon XP 1700 w / 512 megs of ram. I frequently get to 100%, then 30 minutes to an hour later It'll start a new packet. This is went the computer is otherwise not in use. At this point, I just assume 7 1/2 hours per plus or minus. As a side note, what's the slowest system successfully completeing packets. I had a Celeron 333 w / 32 megs ram and Win 95, but had to uninstall BOINC as it couldn't complete a packet before it expired. :-( William D. Gagliardi |
Divide Overflow Send message Joined: 3 Apr 99 Posts: 365 Credit: 131,684 RAC: 0 |
The status bar completion countdown is an ESTIMATE. They've gotten much better at the progress estimation from the past, but this status is a rough aproximation only! The WU will be done when it's done. Clock watching isn't going to hurry it along any. Perhaps a future version of the SETI@Home applicaiton will do a better job at reporting when it is actually done, but it's just not a high priority right now. |
Thierry Van Driessche Send message Joined: 20 Aug 02 Posts: 3083 Credit: 150,096 RAC: 0 |
> I watched a few WU's keep crunching after they reach 100%, but haven't seen > any that take more than a minute or two to complete. Has anyone else seen "a > few hours to completion" after reaching 100%? Using a P4 2.4@2.88GHz with 512MB RAM, together with v4.07 of the application, it crunch in the range of 4h. and some 15min. I see some resttime of 1, maybe max. 2min. bewteen the 100% status and finishing the processing. |
Dave Mickey Send message Joined: 19 Oct 99 Posts: 178 Credit: 11,122,965 RAC: 0 |
>As a side note, what's the slowest system successfully completeing packets. I >had a Celeron 333 w / 32 megs ram and Win 95, but had to uninstall BOINC as it >couldn't complete a packet before it expired I've got a 333MHz Celeron w/64MB that does current units in about 20 hours. My Pentium I 233/96MB does one in about 36 hours. When it gets to 100%, it takes about another hour or so to really finish. Maybe something else was eating cycles, but it seems like your Celeron should not take > 14 days for a unit. That statistic seems to be off by at least an order of magnitude. Could the small RAM number make it that bad? Or WIN95? For comparison, I have a 66MHz/36MB drone that does a Classic WU in about 2 weeks, so it would seem like that speed is somewhere near the (s)low-end limit. Dave |
rsisto Send message Joined: 30 Jul 03 Posts: 135 Credit: 729,936 RAC: 0 |
I have a 600Mh Pentium W2K with S@H installed as a service which had been running almost a week and had not finished one wu. The problem was the screensaver which was one of the 3D Open Gl ones. When the screensaver kicked in, it consumed almost all CPU. When I changed the screensaver to one of the standard ones, wu began to take just around 14 hours. |
Will H Send message Joined: 19 Dec 02 Posts: 6 Credit: 422,493 RAC: 0 |
I've never seen it take much longer after 100%, at most maybe 5mins, but that's it :) If you get BOINCLogX ( http://www.bjoernhenke.de/boinclogx/index.en.htm ) that appears to be showing me the right values (BOINC is saying 50%, BOINCLogX is saying 35%). <img src="http://boinc.mundayweb.com/one/stats.php/userID:5/trans:off/.png"> |
Terry Send message Joined: 17 Sep 00 Posts: 153 Credit: 1,805,202 RAC: 0 |
> I have a 600Mh Pentium W2K with S@H installed as a service which had been > running almost a week and had not finished one wu. The problem was the > screensaver which was one of the 3D Open Gl ones. When the screensaver kicked > in, it consumed almost all CPU. When I changed the screensaver to one of the > standard ones, wu began to take just around 14 hours. > Why use a screen saver at all? I have mine to go to a blank screen and turn the monitor off. |
Thierry Van Driessche Send message Joined: 20 Aug 02 Posts: 3083 Credit: 150,096 RAC: 0 |
> Why use a screen saver at all? I have mine to go to a blank screen and turn > the monitor off. I'm doing the same. I don't use the S@H screensaver, screensaver is set to blank after 5 minutes and monitor off after 20 minutes. Using the S@H screensaver does use a lot of CPU power and will make the clock time of crunching a WU much longer. |
taltamir Send message Joined: 30 Jul 99 Posts: 96 Credit: 51,791 RAC: 0 |
If an estimate is off by THAT much, its better to just get rid of it to avoid confusion. I do not have a superman complex; for I am God, not superman! |
JAF Send message Joined: 9 Aug 00 Posts: 289 Credit: 168,721 RAC: 0 |
> If an estimate is off by THAT much, its better to just get rid of it to avoid > confusion. > The problem is, the estimate is used to calculate how many WU's are to be downloaded, based on one's preferences. So you need to keep that in mind the estimate Seti uses and your preferences (connect to network about every x days) to determine how much work to cache. If Seti thinks your completion rate is 6 WU per day, four days of work is 24 WU's. If it's 3 per day, it's 12. So knowing your estimated crunching rate should keep you in the ballpark" as to your cache size. I suspect the estimates will improve over time, after the more important bugs are fixed. That's about the only thing that's good about using a dial-up connection (of course the cost is too!) You notice more about each WU transaction, since it's slower and you control when the transfer takes place. <img src='http://www.boincsynergy.com/images/stats/comb-912.jpg'> |
taltamir Send message Joined: 30 Jul 99 Posts: 96 Credit: 51,791 RAC: 0 |
i didnt say drop the code.. i meant make it not display a progress bar.. Besides, why use an estimate? use previous data instead, see how long it takes a computer to do a work unit, average the times from the different workunits... I do not have a superman complex; for I am God, not superman! |
John McLeod VII Send message Joined: 15 Jul 99 Posts: 24806 Credit: 790,712 RAC: 0 |
> i didnt say drop the code.. i meant make it not display a progress bar.. > > Besides, why use an estimate? use previous data instead, see how long it takes > a computer to do a work unit, average the times from the different > workunits... > For the same reason that WU counting does not work. Some S@H WUs take 5 minutes, and some take 10 hours, and the distribution is multi modal, not bell shaped. BOINC WIKI |
Benher Send message Joined: 25 Jul 99 Posts: 517 Credit: 465,152 RAC: 0 |
Seems a compromise would work well. Base # of mins remaining on previous results... If it is a quickie WU (5 min or less) then the bar will be totally inaccurate (it will suddenly jump to 100%)...but who will be watching the screen to catch these few =) |
taltamir Send message Joined: 30 Jul 99 Posts: 96 Credit: 51,791 RAC: 0 |
Well, I meant use over time benchmarking. Right now there is a benchmark at the begining, and then it just uses that data to estimate. Well, that data isnt always accurate because CPU load differs over time. If you can estimate how long one work unit is going to take, you can apply the same "estimation" to compare two work units. If one is estimated to take 1 hour on your computer, one estimated to take 2 hours, second one is then estimated to take twice as long as the first unit. If the first unit actually took 2 hours, assume the second unit will take 4 hours. Thats what I meant. I do not have a superman complex; for I am God, not superman! |
©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.