BOINC now supports ATI GPUs.
The client detects them and manages their work queue as it does for NVIDIA GPUs.
This will be in the 6.10 client, which should be released in a month or so.
The server code now also accommodates ATI GPUs.
In addition, the coprocessor model has been extended
to allow jo
El Miércoles 19 Ago 2009 19:37:45 Mark Pottorff escribió:
> I've been reviewing BOINC server code and the BOINC server VM. All of the
> distributed data command line programs indicate they should be run from the
> project root directory, however I don't find them there.
>
> If found request_file_li
On Wed, Aug 19, 2009 at 4:16 PM, Mark
Silberstein wrote:
> I claim ( actually not only me, there's been some research on that on large
> machines) that the slow down wouldn't be 25% but 50%, since the perf. of
> multithreaded application would be dominated of the perf. of the slowest
> thread. Cons
> The Multi threaded application would slowdown by 25%. (half of half of the
> CPUs are in use).
I claim ( actually not only me, there's been some research on that on large
machines) that the slow down wouldn't be 25% but 50%, since the perf. of
multithreaded application would be dominated of the
I've been reviewing BOINC server code and the BOINC server VM. All of the
distributed data command line programs indicate they should be run from the
project root directory, however I don't find them there.
If found request_file_list, get_file, send_file, and delete_file all in the
/boinc/sched
Ah. Missed that.
Sorry.
Eric
On Wed, Aug 19, 2009 at 12:06 PM, wrote:
> Actually, on a 4 CPU system Dave was talking about allowing 2 CPUs or 50%
> of the CPUs to overlap.
>
> The single threaded applications would each have a slowdown of 50% as they
> shared their single CPU 50/50 with the mu
Actually, on a 4 CPU system Dave was talking about allowing 2 CPUs or 50%
of the CPUs to overlap.
The single threaded applications would each have a slowdown of 50% as they
shared their single CPU 50/50 with the multi CPU task.
The Multi threaded application would slowdown by 25%. (half of half
On Wed, Aug 19, 2009 at 11:53 AM, Eric J
Korpela wrote:
> On Tue, Aug 18, 2009 at 4:34 PM, Mark
> Silberstein wrote:
>> But, by slowing down the
>> multithreaded app performance, it'd make it, I'd say, not really beneficial
>> to bother with multithreaded implementation.
>
> We're only talking abo
On Tue, Aug 18, 2009 at 4:34 PM, Mark
Silberstein wrote:
> But, by slowing down the
> multithreaded app performance, it'd make it, I'd say, not really beneficial
> to bother with multithreaded implementation.
We're only talking about an (NCPU-1)/NCPU slowdown (25% on a 4CPU
box). Besides, it's a
OK, in that case, add the light weight negotiation.
jm7
"Kamran Karimi"
To
Sent
The current method of communicating the number of threads to an MT app (via a
command line argument) is a simple solution that works.
However scheduling MT apps along with single-thread apps can always be
improved.
-Kamran
___
boinc_dev mailing list
Sorry, I got side-tracked after uploading the last 6.6 release. I had
thought I had made that a public release already.
- Rom
From: ksmarksps...@gmail.com [mailto:ksmarksps...@gmail.com] On Behalf
Of Kathryn Marks
Sent: Tuesday, August 18, 2009 8:06 PM
To: Rom Walton
Cc: boinc_dev@ssl.
That is probably what I'm going to have to do.
There are many small customizations that'll have to be ported over to the new
version. The most important is the form-based authentication changes to
support SSL.
I'm going to get the 6.10 kick started and then switch to working on this
issue. I
That's the main problem with upgrades, try first to duplicate the
setup in a virtual machine and try there the upgrade first. It could
be useful to have first a proof of concept.
Daniel
2009/8/19 Rom Walton :
> Well, it requires Trac to be version 0.11 or better to work properly.
>
> Hence, a pai
Well, it requires Trac to be version 0.11 or better to work properly.
Hence, a painful upgrade.
- Rom
-Original Message-
From: teleyi...@gmail.com [mailto:teleyi...@gmail.com] On Behalf Of Daniel
Lombraña González
Sent: Wednesday, August 19, 2009 8:18 AM
To: Rom Walton
Cc: Eric Myer
A random thought:
How about a plan_class for negotiable CPU usage. The task would have to
supply the max and min # of CPUs it can use. I have not looked at the XML
for a plan class, it might be as simple as adding the minimum # of CPUs
acceptable to the plan class.
BOINC would keep a # number i
I believe (correct me if I am wrong please) that control information is
passed through a memory buffer. The request for specific CPU usage should
be passed through that. If it is optional, the project can play nice if it
can, but can ignore the request if it is very difficult. Even better would
That could be the best solution ;)
On Tue, Aug 18, 2009 at 9:20 PM, Rom Walton wrote:
> There is a newer spam filter for Trac that supports Captcha.
>
> - Rom
>
> -Original Message-
> From: boinc_dev-boun...@ssl.berkeley.edu
> [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of Er
18 matches
Mail list logo
