> Ok, for information only ... speculation only ...
>
> The core client (depreciated term, correctly known as The BOINC Work
> Manager) can affect the total execution times of the science applications.
> We are now running, or should be running BOINC Work Manager v 4.13 ...
>
> Since the BOINC Work Manager does many of the tasks needed by the science
> application there has to be communitcation between the science application, in
> this case SETI@Home v 4.05; if those calls through the API (Application
> Programming Interface) take more time, then the processing time will rise.
>
> So, if they made a change to a process/function in the BOINC Work Manager and
> that process/function now takes longer to execute, your total time will rise
> ... especially if it is a function that is called a lot ...
>
> This is the reason you wait until the application is released before you
> optimize. You only want to look at places where you can make changes to truly
> affect the total run time. The bottom line right now is that we do not know
> exactly where the problem lies and that is what they are trying to determine
> now ...
>

Hi Paul,

First off, sorry if this has been covered before - I haven't re-read every post in this thread.

A nice theory Paul, but I'm going to disagree with you on this. I don't think the BOINC Work Manager interacts at all with the science client while it's processing. My reason being is that you can simply run the science client by itself without the BOINC Work Manager even being present on the system, for example, as you can do for the test reference work unit (just place the seti client and the renamed reference work unit in the same directory and execute).

Anyway, one sure way to tell if the BOINC Work Manager affects the processing time would be to run the test reference work unit with two different versions of the BOINC Work Manager (say, 4.09 versus 4.13) but with the same seti science client (4.05) and compare the processing times.

I still believe we are simply seeing variation in work units and nothing more :)

Ned

---

*** My Guide to Compiling Optimised BOINC and SETI Clients ***
*** Download Optimised BOINC and SETI Clients for Linux Here ***

Examining my message log, it appears that the CPU time keeps running when the application is suspended due to time of day - shrug!

---

> Making the assumption that the work units have remained relatively constant;
> then V4.13 is preocessing them, slightly, faster than v4.12 & v4.11
> but still slower than v4.09. -H. Richard Utzig
>

Yes I agree a 100% with Richard, in my case, there is no problem on continuos time advancing, nor anything else.
In fact there have been a couple of the last units that were very close in time to the time I was obtaining when the cc 4.09

Using now the 4.13 on 2.67GHz pentium 4 RAM 256MB using WXP P1.

---

Patience is a virtue.

> Yes I agree a 100% with Richard, in my case, there is no problem on continuos
> time advancing, nor anything else.
>
Curious. Do your WU ever pause during calcution to work on another project or during certain time of day?

---

> Hi Paul,
>
> First off, sorry if this has been covered before - I haven't re-read every
> post in this thread.
>
> A nice theory Paul, but I'm going to disagree with you on this. I don't think
> the BOINC Work Manager interacts at all with the science client while it's
> processing. My reason being is that you can simply run the science client by
> itself without the BOINC Work Manager even being present on the system, for
> example, as you can do for the test reference work unit (just place the seti
> client and the renamed reference work unit in the same directory and
> execute).
>
> Anyway, one sure way to tell if the BOINC Work Manager affects the processing
> time would be to run the test reference work unit with two different versions
> of the BOINC Work Manager (say, 4.09 versus 4.13) but with the same seti
> science client (4.05) and compare the processing times.
>
> I still believe we are simply seeing variation in work units and nothing more
> :)
>
> Ned

That is one of the nice things about this system, we can each have a theory ... :)

I know that SETI@Home WU have a variance that can be caused by Angle Rate, and more by the signal content ... And there is no way to easily prove/disprove that these are the overwhelming issue right now. I am not saying you are wrong, you well may be correct ...

I was just making the point that seemingly trivial changes to code and dramatically impact the operation of the system. One of the examples I have pointed to in the past is the problem where the BOINC GUI on windows continues to update the window content even when the window is not visible (which is also a violation of normal GUI rules, but I am not beating up on the developers, I am not that into timing issues, and this is not the long term GUI so, who cares...) ...

Ok, for an explicit example of what I said:

Loop-start-1,000,000
=> do something (taking 1 usec)

In this case, we have a loop that does one million operations, each taking a microsecond; do that one million times and you have a one second elapsed time. Because it is burried in a loop that is executed so many times, minor changes in the inner part of the loop will radically change the total execution time.

In this case, we have the science application doing work and it must communicate with the GUI or CLI to do things like telling it how long it has been running etc.

I am not asserting that this is the case, just saying that it is possible ...

---

> > > OT @ Papa Zito.
> > >
> > > This may sound like a strange question if you don't know what I'm
> > talking
> > > about, but are you Papa Zito from Kingdom of Loathing?
> > >
> >
> > *grin* Why yes, I am.
>
> I thought so...
>
> I just started playing it, and saw your name on the various fora. I didn't
> think there could be too many Papa Zito's around. :)

This is probably a good thing.

---

> No, that's not really the case. If your cache is sized right you'll be just
> fine in spite of it underestimating your time to process.
>
>...more stuff...

That negates the entire point to having a cache, plus it doesn't solve the underlying problem. In addition, not everyone crunches 100%... some people actually use the program as it's meant to be used.

---

> we have the science application doing work and it must
> communicate with the GUI or CLI to do things like telling it how long it has
> been running etc.
>
> I am not asserting that this is the case, just saying that it is
> possible ...
>
Well said Sir! My gut says something is afoot.

>
> In this case, we have the science application doing work and it must
> communicate with the GUI or CLI to do things like telling it how long it has
> been running etc.
>

OK, I think we're just interpreting things a little differently, that's all :)

I interpret it as the science client is writing things like this to log files and the Work manager is reading the data from these log files, thus they are communicating indirectly with each other. That's different to the two apps communicating directly with each other where one can directly affect the processing time of the other.

Ned

---

*** My Guide to Compiling Optimised BOINC and SETI Clients ***
*** Download Optimised BOINC and SETI Clients for Linux Here ***

> I know that BOINC versions should not affect the SETI processing, but mine
> seem to be taking even longer - help!

I had no difference in processing time when i upgraded from 4.12 to 4.13.
However when the Seti client went from 4.03 to 4.05 the processing time went from 3hrs 15 min to over 5 hours per Work Unit.

---

Grant
Darwin NT

I have discovered that they "appear" to be taking longer because the CPU time increases even when they are suspended. I think this started with 4.13

---

I guess it's because there is more analyzation... who knows? I'm getting more credit, and there's a better chance to find something... an extra hour for me doesn't matter. :-)

---

<a href=\"http://setiweb.ssl.berkeley.edu/\" target=\"blank\"><img src=\"http://boinc.mundayweb.com/seti2/stats.php?userID=1352&trans=off\">

No. What UDScribe is saying is that while WU calculation is paused, BOINC counts CPU time as though the WU is still being proccessed.
I noted the same observation in this Post .
Previous versions had this same 'bug' but on restart of calculation the CPU count seemed to revert back to CPU time that it was originally paused at. With 4.13 this does not happen and CPU time is counted even while WU is not being analyzed.

> > No, that's not really the case. If your cache is sized right you'll be
> just
> > fine in spite of it underestimating your time to process.
> >
> >...more stuff...
>
> That negates the entire point to having a cache, plus it doesn't solve the
> underlying problem. In addition, not everyone crunches 100%... some people
> actually use the program as it's meant to be used.
>
The computers historical % spent actually crunching vs wall clock is applied to the amount of work requested. This means that if your computer spends 50% of the time on, and only 50% of that time crunching, when you ask for 4 days of work, you will get 1 days worth of work if you crunched at 100%. New hosts are assumed to crunch 100% of the time until proven otherwise.

The developers noticed that some of the benchmark code was being removed by the optimizer because the results were not being used. The results of the benchmarks are now being stored so that the optimizer will not remove the calculations. This has changed the estimated times to complete a calculation for 4.13.

---

BOINC WIKI

> >
> >
> The computers historical % spent actually crunching vs wall clock is applied
> to the amount of work requested. This means that if your computer spends 50%
> of the time on, and only 50% of that time crunching, when you ask for 4 days
> of work, you will get 1 days worth of work if you crunched at 100%. New hosts
> are assumed to crunch 100% of the time until proven otherwise.

Eh, okay, it's smarter than I thought.

There's still the original problem: downloading more than it can handle.

---

> > No, that's not really the case. If your cache is sized right you'll be
> just
> > fine in spite of it underestimating your time to process.
> >
> >...more stuff...
>
> That negates the entire point to having a cache, plus it doesn't solve the
> underlying problem. In addition, not everyone crunches 100%... some people
> actually use the program as it's meant to be used.
>
Computer programs can only have a limited amount of intellegence built into them (otherwise they just start getting bigger and bigger as you slap more 'intellegence' into them). If the complexity of your environment is too much for the program's current algorithm used to calculate the cache size, you may need to do some tweaking until it works right for you.

It's impossible to write a program that can handle every single user's environment...they write it to handle the vast majority of users. Users who fall outside of the norm have to take some responsibility for adjusting the preferences to suit their needs (that's why they're Preferences, not hard-coded values!)

If the value you give it results in WUs staying in your cache beyond the timeout period, then CHANGE THE VALUE TO SOMETHING LOWER!

All said and done, I would just like to know why the processing
times for some of my computers has jumped loads. Not just 1/2 hr
on one machine - but almost doubled on some and 10-30 % on others.

Is it better science or ........

Nairb

---

......or they are suspended? If so they still clock up CPU time.

---