Program reaches 25% in a minute, then takes 3 hours to finish.

Questions and Answers : Windows : Program reaches 25% in a minute, then takes 3 hours to finish.

To post messages, you must log in.

AuthorMessage
Michael Schwebs

Send message
Joined: 3 Apr 99
Posts: 10
Credit: 511,213
RAC: 0
United States
Message 1550 - Posted: 25 Jun 2004, 0:25:59 UTC

I was wondering if this was a glitch. Sometimes, when it starts a new workunit, it instantly starts searching for Spikes/Guassians/Triplits.

In about a minute, it says its 25% done, then starts doing the Fast Forum transform.

the remaining 75% takes about 3 hours.

I was wondering if a programmer messed up somewhere.

ID: 1550 · Report as offensive
Profile Ageless
Avatar

Send message
Joined: 9 Jun 99
Posts: 13810
Credit: 3,269,733
RAC: 0
Netherlands
Message 1556 - Posted: 25 Jun 2004, 0:33:32 UTC

Nope, this is by design.

Unless you have a workunit filled with "noise", but you'd be able to check that in the stderr of the unit once returned to the site.


----------------------
Jord™
[url=http://www.boinc.dk/index.php?page=user_statistics&userid=41965]

ID: 1556 · Report as offensive
Profile David Dyer-Bennet

Send message
Joined: 8 Apr 99
Posts: 9
Credit: 4,280,317
RAC: 0
United States
Message 2103 - Posted: 25 Jun 2004, 20:21:29 UTC - in response to Message 1556.

> Nope, this is by design.

Well, it's a bad design. I know it's hard to make a well-behaved progress indicator when multiple steps are being done, or when the actual work is very non-uniform; but this grotesque degree of non-linearity *by design* is just wrong.

I've had my own runins with implementing progress indicators at work, and been told that by others, sorry if my satisfaction of getting to pass it on is too evident :-).

ID: 2103 · Report as offensive
Heffed
Volunteer tester

Send message
Joined: 19 Mar 02
Posts: 1856
Credit: 40,736
RAC: 0
United States
Message 2139 - Posted: 25 Jun 2004, 21:05:12 UTC - in response to Message 2103.

> Well, it's a bad design. I know it's hard to make a well-behaved progress
> indicator when multiple steps are being done, or when the actual work is very
> non-uniform; but this grotesque degree of non-linearity *by design* is just
> wrong.
>
> I've had my own runins with implementing progress indicators at work, and been
> told that by others, sorry if my satisfaction of getting to pass it on is too
> evident :-).

HeHe... You'd totally freak out if you saw how it behaves with debug active. ;-)

ID: 2139 · Report as offensive
Profile Shaktai
Volunteer tester
Avatar

Send message
Joined: 16 Jun 99
Posts: 211
Credit: 259,752
RAC: 0
United States
Message 2242 - Posted: 26 Jun 2004, 3:02:42 UTC - in response to Message 2139.

>
> HeHe... You'd totally freak out if you saw how it behaves with debug active.
> ;-)

Aahh, debug. Such fond memories of unpredictable activity. :-)

Since the intial nature of a work unit is not known until it is processed, it is very difficult to develop a truly predictable progress indicator. There is no way of knowing how long various aspects of the actual work unit will take. Typically they start off fast and then slow down, but each and every one is different. The nature of the work (calculations) is not strictly linear, but more a matter of erratic peaks (lots of information to process) and valleys (little information to process) that vary dramatically from one work unit to another. Very difficult to predict.

ID: 2242 · Report as offensive
John McLeod VII
Volunteer developer
Volunteer tester
Avatar

Send message
Joined: 15 Jul 99
Posts: 24806
Credit: 754,585
RAC: 140
United States
Message 2254 - Posted: 26 Jun 2004, 4:32:32 UTC - in response to Message 2242.

> >
> > HeHe... You'd totally freak out if you saw how it behaves with debug
> active.
> > ;-)
>
> Aahh, debug. Such fond memories of unpredictable activity. :-)
>
> Since the intial nature of a work unit is not known until it is processed, it
> is very difficult to develop a truly predictable progress indicator. There is
> no way of knowing how long various aspects of the actual work unit will take.
> Typically they start off fast and then slow down, but each and every one is
> different. The nature of the work (calculations) is not strictly linear, but
> more a matter of erratic peaks (lots of information to process) and valleys
> (little information to process) that vary dramatically from one work unit to
> another. Very difficult to predict.
>
> <a> href="http://www.boinc.dk/index.php?page=user_statistics&userid=153364"> [/url]

ID: 2254 · Report as offensive
Profile Thierry Van Driessche
Volunteer tester
Avatar

Send message
Joined: 20 Aug 02
Posts: 3083
Credit: 150,010
RAC: 132
Belgium
Message 2314 - Posted: 26 Jun 2004, 9:37:37 UTC
Last modified: 20 Jul 2004, 13:53:15 UTC

When Boinc was in the starting phase, the CPU timings against percentage done were even stranger then it is now.
See this graph.

Greetings from Belgium.

ID: 2314 · Report as offensive

Questions and Answers : Windows : Program reaches 25% in a minute, then takes 3 hours to finish.


 
©2016 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.