Hi

I am running the following on all my hosts.

BOINC 3.20
SETI 3.08
PREDICTOR 3.07

The problem I am having is even with Seti at 80% and Predictor at 20% I am receiving too many Predictor Units.

The problem seems to be that when a Seti unit is downloaded it has an estimated time of between 30 - 40 hours depending on the Host. When in fact the correct time is between 2 and 6 hours.

Predictor on the other hand is loaded with an estimate of 1.5 and 2 hours and in fact takes between 3 and 4 hours to complete.

This has the affect of loading a large number of Predictor units and very few Seti. This is the opposite of what I want.

Seti is the prime work unit that I want to work as I started Predictor only because Seti could not deliver work units.

I hope that something can be done about this problem. I have just dropped Predictor down to 10 / 90 split with Seti but I do not think it will help much. I havent tried putting Predictor at a minus ??

As of right now you can't really do anything about it... seti@home changed a setting that increased the estimated processing time by a factor of 6 or more. Eventually they will correct this error and your processing priority will work again. But for now you will either have to detach from predictor or just let it go. The jury is still out on wether or not this was an accident or a deliberate action to decrease everyone's queues and thereby reduce the number of outstanding workunits.

> As of right now you can't really do anything about it... seti@home changed a
> setting that increased the estimated processing time by a factor of 6 or more.
> Eventually they will correct this error and your processing priority will
> work again. But for now you will either have to detach from predictor or just
> let it go. The jury is still out on wether or not this was an accident or a
> deliberate action to decrease everyone's queues and thereby reduce the number
> of outstanding workunits.
>
>

I set Seti to be 90% and Predictor at 10% and now the Seti units are starting to come.

HI Dingo

I`ve just downloaded some new WUs and the extended WU times seems to have been
fixed, so you may next time you try you may find your problem sorted

M4rtyn

The project contacted is the one with the highest resource debt. Recource debt is calculated from the recent average CPU time spent on the projects, and the resource shares for the projects. Turn the resource shares for the projects running on that computer into percentages. Turn the recent average CPU or each project into percentages. Now subtract the recent average CPU percentage from the resource share percentage. Sort the projects into the order highest to lowest. Now start contacting the projects in order to fill the queue. If a project does not have work, try the next project.

The recent average CPU usage starts at 0 for a new project, wo it can be a while before this number is built up enough to start switching to the older project(s).

If a project cannot fill the cache, the next project in line is querried for work.

The other problem related to this for me is that all the predictor WUs have a shorter report deadline time and the scheduler will run them before it will run a SAH WU. This keeps happening even though I have the percentages set to 90%
SAH and 10% Predictor - the opposite seems to be happening. It doesn't help that SAH estimates the processing time at 6 times actual or that when a system asks for work there often isn't any and it will fill up with Predictor WUs. I think the algorithm needs to be revisited based on recent history. Of course this could all be solved more easily with a SetiQ approach. The lack of control of a large number of systems is a big step backwards relative to Classic SAH with SetiQ.

> The other problem related to this for me is that all the predictor WUs have a
> shorter report deadline time and the scheduler will run them before it will
> run a SAH WU. This keeps happening even though I have the percentages set to
> 90%
> SAH and 10% Predictor - the opposite seems to be happening. It doesn't help
> that SAH estimates the processing time at 6 times actual or that when a system
> asks for work there often isn't any and it will fill up with Predictor WUs. I
> think the algorithm needs to be revisited based on recent history. Of course
> this could all be solved more easily with a SetiQ approach. The lack of
> control of a large number of systems is a big step backwards relative to
> Classic SAH with SetiQ.
>
What is probably happening to you is a lack of work available from S@H. If the work is not there, nobody can get it. In this case Predictor is just filling in the gaps.