Less Redundancy
29 Mar 2005 16:29:54 UTC
Topic 188795
(moderation:
Please reduce the amount of redundancy that is employed as it is depriving other projects of computer time while we are needlessly crunching a qourum of 4 when the absolute max needed is 3. Seti is guilty and so is Einstein. I know its so that they can grant credit faster and delete the unit from their disks but its not justified. In effect for every 100 computers only 25 are doing any real work the others are only duplicating. You need redundancy but not that much.
Less Redundancy
)
> Please reduce the amount of redundancy that is employed as it is depriving
> other projects of computer time ....
You made this assertion in another post and someone corrected you there. Perhaps you didn't actually see it.
Let's say a million new users decide to sign up to both E@H and some other Boinc project. Let's also say that they all set their resource share to 50/50. Then the nasty E@H developers decide to screw us all by resetting the "redundancy" to 20. Please calculate for us how many cpu cycles the "other" project will be deprived of as a result of this nasty change? You will need the linux client with its superior accuracy to work this out :).
Cheers,
Gary.
> Let's say a million new
)
> Let's say a million new users decide to sign up to both E@H and some other
> Boinc project. Let's also say that they all set their resource share to
> 50/50. Then the nasty E@H developers decide to screw us all by resetting the
> "redundancy" to 20. Please calculate for us how many cpu cycles the "other"
> project will be deprived of as a result of this nasty change? You will need
> the linux client with its superior accuracy to work this out :).
It depends really on the amount of work that is theoretically possible for E@H.
If enough users sign up that work can be processed as fast as E@H can generate it, then the server will sometimes respond with "no work available", and a proportion of the computers fall back to (up to) 100% on the other project.
At one extreme (E@H has an infinite amount of work available) every CPU cycle being added to create extra redundancy for E@H is depriving only E@H of its own progress.
At the other extreme (E@H does not have enough work to fulfil all requests), any additional redundancy is depriving other projects.
(thinks)
hmmm... wouldn't it be good if the client could indicate to the server whether denying it a work unit would make the processor Idle or make it merely move on to another project? That way the server could preferentially give out new work units to processors that would otherwise be sitting idle.
> hmmm... wouldn't it be good
)
> hmmm... wouldn't it be good if the client could indicate to the server whether
> denying it a work unit would make the processor Idle or make it merely move on
> to another project? That way the server could preferentially give out new work
> units to processors that would otherwise be sitting idle.
If you run different projects with a certain time share, none of the other projects will be affected by redundancies of one certain project.
For me it's:
40% CPDN,
30% Einstein,
20% SETI and
10% ProteinPredictor
The time share is fixed, and if the projects requires more redundancy, it will just get less WUs ready in a certain time, but more accurate results. Einstein will always get 30% on my puters, regardless of any other projects. Only exception: if one projects runs out of work, and can't deliver new WUs, the share will be divided to the others. So a behaviour like classic Seti (sending out WUs up to 30 times) will possibly affect other projects, but I don't think that that's a common occurance in Boinc.
Grüße vom Sänger
> > hmmm... wouldn't it be
)
> > hmmm... wouldn't it be good if the client could indicate to the server
> whether
> > denying it a work unit would make the processor Idle or make it merely
> move on
> > to another project? That way the server could preferentially give out new
> work
> > units to processors that would otherwise be sitting idle.
>
> If you run different projects with a certain time share, none of the other
> projects will be affected by redundancies of one certain project.
>
> For me it's:
> 40% CPDN,
> 30% Einstein,
> 20% SETI and
> 10% ProteinPredictor
>
> The time share is fixed, and if the projects requires more redundancy, it will
> just get less WUs ready in a certain time, but more accurate results. Einstein
> will always get 30% on my puters, regardless of any other projects. Only
> exception: if one projects runs out of work, and can't deliver new WUs, the
> share will be divided to the others. So a behaviour like classic Seti (sending
> out WUs up to 30 times) will possibly affect other projects, but I don't think
> that that's a common occurance in Boinc.
>
It is a fairly common occurrence with BOINC projects to run out of work. LHC admits to having work intermittently. Pirates is mostly not handing out work. BURP has work every couple of weeks. CPDN servers occasionally will not hand out work. S@H has had outages as long as a couple of weeks. PP@H has had an outage for 4 months...
BOINC WIKI