I only started BOINC yesterday & with the server down was unable to get any WU's. I was keen to see BOINC work so I joined Predictor@home and that's working great. My problem now is I think my cache is full with Predictor WU's and when I select Seti to 'update', that appears to be working Ok now but doesn't download any WU's. I've set Seti to process more than Predictor but that hasn't helped.
I've even tried adding a couple of days to the allowed cache, no effect.
Or is the server not delivering yet?
Also, 'Show Graphics' is greyed out on Predicter units. Is this normal?
Thanks
Mark

You won't get any SAH workunits until they're available...which thy're not.

Keep crunching on the Predictor ones man. My machines are completely idle now thanx to the crappy SAH implementation thats in place so I may be joining you just to keep busy.

Don't worry. When the servers of SETI/BOINC star giving WU more regularly, you will get them.
The Predictor@Home is still in Alpha phase. There is talk of graphics later. Maybe in Beta...

> You won't get any SAH workunits until they're available...which thy're not.
>
> Keep crunching on the Predictor ones man. My machines are completely idle now
> thanx to the crappy SAH implementation thats in place so I may be joining you
> just to keep busy.
>
>
why not run classic seti???
ttyl
Jeff

This is normal behavour. When the cache hist the low water mark, then the cache will refill form the project with the greatest resource debt. When joining a new project after running BOINC with other projects for a while, you should expect a few weeks where the new project will dominate the work load until it catches up in recent average CPU usage.

> This is normal behavour. When the cache hist the low water mark, then the
> cache will refill form the project with the greatest resource debt. When
> joining a new project after running BOINC with other projects for a while, you
> should expect a few weeks where the new project will dominate the work load
> until it catches up in recent average CPU usage.
> <a> href="http://www.boinc.dk/index.php?page=user_statistics&userid=9915">
>
>Are you suggesting the cache works to level all work done between the projects vs. just slicing cpu time between the currently loaded work units? That's kind of dumb! If that is true, then the user (you and me) has NO real control over which project utilizes our resources should we wish to suppport more than one project at a time.... If the system plays catch-up processing because a project was down (due to tech problem or ?) the other projects in effect suffer. There is no need for a project group to be effective in their design and implementation of their project, in this configuration they will get the cycles regardless of their incompetence. I may have to rethink which projects, if any, I will support. I would expect the BOINC system to be generic in its treatment of projects, if data is available process it based on the users preferences (time slice allocation), otherwise there is no catch-up.

> > This is normal behavour. When the cache hist the low water mark, then
> the
> > cache will refill form the project with the greatest resource debt.
> When
> > joining a new project after running BOINC with other projects for a
> while, you
> > should expect a few weeks where the new project will dominate the work
> load
> > until it catches up in recent average CPU usage.
> > <a>
> href="http://www.boinc.dk/index.php?page=user_statistics&userid=9915">
> >
> >Are you suggesting the cache works to level all work done between the
> projects vs. just slicing cpu time between the currently loaded work units?
> That's kind of dumb! If that is true, then the user (you and me) has NO real
> control over which project utilizes our resources should we wish to suppport
> more than one project at a time.... If the system plays catch-up processing
> because a project was down (due to tech problem or ?) the other projects in
> effect suffer. There is no need for a project group to be effective in their
> design and implementation of their project, in this configuration they will
> get the cycles regardless of their incompetence. I may have to rethink which
> projects, if any, I will support. I would expect the BOINC system to be
> generic in its treatment of projects, if data is available process it based on
> the users preferences (time slice allocation), otherwise there is no catch-up.
>
>

Participating in multiple projects


CPU Scheduling in Ver 4.05
Client scheduling policies





M7 Seti@h Berkeley's Staff Friends Club ©

> Are you suggesting the cache works to level all work done between the
> projects vs. just slicing cpu time between the currently loaded work units?
> That's kind of dumb! If that is true, then the user (you and me) has NO real
> control over which project utilizes our resources should we wish to suppport
> more than one project at a time.... If the system plays catch-up processing
> because a project was down (due to tech problem or ?) the other projects in
> effect suffer. There is no need for a project group to be effective in their
> design and implementation of their project, in this configuration they will
> get the cycles regardless of their incompetence. I may have to rethink which
> projects, if any, I will support. I would expect the BOINC system to be
> generic in its treatment of projects, if data is available process it based on
> the users preferences (time slice allocation), otherwise there is no catch-up.
>
The way that this works has changed. There are currently problems with projects that have short deadlines (Predictor sometimes), slow machines, and low resource shares. In all of these cases, it is easy to have a computer that will never get credit for some or all of the work that it does because it cannot complete the work on time because of time slicing. I have a couple of computers that I do not expect to get credit from until less work is downloaded at once. On these computers there is only one WU per project downloaded, but since they are slow enough, with time slicing, all work will be reported after the deadline has passed.

Not all projects will have work all of the time. In some cases, it is because observations generate the data to crunch, and the observations can not be run on all days. In others, because of the heavy demand may be consistently short of WUs.

In any case, the old method used a long term approach to balancing work between projects which has the drawback that a project that is down gets preference when it comes back up. The current scheme has the draw back that user options for resource share and projects attached to are driven by computer speed, not by user wishes.

I would like to see some hybrid approach that would avoid downloading work if there is already nearly the maximum that can be crunched for that computer, and allowing a project that has had its download deferred by the BOINC client to increase its resource share debt so that it will make up the crunch time when the client does allow it to download work.