We are not dismissing the power users. However, we are looking for a
solution for the problem for everyone, not just for the power users. If we
can identify the problem, find a way to detect the problem, and then code
an automatic fix, we all win. Let us not dismiss the regular fire and
forget user as well.
Yes, having the feedback from testers and power users about the problem is
great. But insisting that the normal users use manual controls to work
around the problem is not.
jm7
Pappa
<m...@geeksamazing
.com> To
Sent by: "'Paul D. Buck'"
<boinc_dev-bounce <[email protected]>, "'Lynn W.
[email protected] Taylor'" <[email protected]>
u> cc
[email protected]
Subject
02/13/2010 12:26 Re: [boinc_dev] 6.10.32 failing to
AM maintain sufficient work
I have machines that because they have Cuda cards have issues because Boinc
only assumes "one" type of hardware resource. With things happening in
Boinc
Alpha I have expanded my projects to look at Project Pairing. Then my
machines make the "best use" of my resources.
The latest is that I reenabled Seti for CPU on a machine that was doing
Seti
on the Cuda card and other projects on the CPU. Because of the single
broken
DCF I now have a TON of work for the CPU. There is no way (currently) to
"balance" that. So while I set NNW and the GPU will starve, it is something
only that an "advanced user" will have knowledge to deal with (micromanage)
A user that got an email from a friend that has a fairly new computer does
not have the advantage of information gained by others or myself that only
know about Boinc Dev, Boinc Alpha and please excuse the term "power users"
provide as information to the masses (pick your project forum).
Generally speaking it is the "power users" (that includes testers) that
identify problems with, which ever Boinc Core or Server Side issues. So
they
have value, please do not dismiss them that easily. They are needed for
that
simple reason.
So the Mom and Pop machine that just quits working because of negative
debt... Oh well they turn it off without knowing why. They have no idea of
who to ask or any indication of what is going on. While it works, they turn
it on in the morning and off when they go to bed. I would point to an
example machine that the wife and I purchased for our parents that ran for
a
while and there was an issue (not saying Seti caused the issue). The vendor
solved the problem and the machine went to their house. I did not reinstall
Boinc on it (no, I do not want to drive for an hour and a half to check on
a
non reporting computer "common sense"). With the addition of a new machine
on my part I was "mistakenly" able to roll into the new machine I had
placed
online (side issue).
That is part of the mystery of "churn." Something happens and they quit. No
reasons or answers as to why. Where does it point?
So for my part, I run Seti on the Cuda resource and Aqua, Simap and other
projects (integer based) on the CPU's Then I do not have cache contention
to
deal with (that goes to the projects that do not properly identify or
manage
what they want to send to the systems "properly" they are all greedy for
the
computer time they can gain). I am doing the "Science" that I can
appreciate
and be useful for. Then I am primarily an AMD User.
Regards
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Paul D. Buck
Sent: Friday, February 12, 2010 12:04 PM
To: Lynn W. Taylor
Cc: [email protected]
Subject: Re: [boinc_dev] 6.10.32 failing to maintain sufficient work
Um, strict FIFO is the *RULE* for GPUs ...
And I agree that it is a failure and a bad policy ...
On Feb 12, 2010, at 11:42 AM, Lynn W. Taylor wrote:
> For example, every so often someone says "why doesn't BOINC always
> process in deadline order, wouldn't that be simpler?" The answer is:
> "because we tried it, and it failed rather spectacularly."
_______________________________________________
boinc_dev mailing list
[email protected]
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.
_______________________________________________
boinc_dev mailing list
[email protected]
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.
_______________________________________________
boinc_dev mailing list
[email protected]
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.
