> For a better design, the BOINC client needs to inform the server of the
models 
> and capabilities, of each GPU, and possibly have the scheduler 
> indicate which tasks can run on which GPUs.

It is not clear that Boinc actually knows the correct video card
capabilities.  One of my computers has the following configuration:

2 x GTX 570
1 x GTX 660
1 x GTX 670

For the 570s Boinc reports:

Data Name                   GTX 570 - 1         GTX 570 - 2
Name:           GeForce GTX 570     GeForce GTX 570
Vendor:              NVIDIA Corporation  NVIDIA Corporation
Driver version:                    344.11              344.11
Version:                OpenCL 1.1 CUDA     OpenCL 1.1 CUDA
 Extensions:              Omitted                   Omitted
Max compute units:               15                   7
Max work group size:           1024                1024
Max clock frequency:        1464Mhz             1084Mhz
 Max memory allocation: 335,544,320         335,544,320 
Cache type:            Read/Write                Read/Write
Cache line size:                      128                       128
Cache size:                     245,670             114,688 
Global memory size:   1,342,177,280           2,147,483,648 
Constant buffer size:         65536                   65536
Max number of constant args:        9                     9
Local memory type:       Scratchpad              Scratchpad
Local memory size:            49151                   49151
Queue properties:                                       
Out-of-Order:                 Yes                       Yes

Note the differences in max compute units, max clock frequency, cache
sizes, and global memory size.

These differences are actually possible.  One of these cards was
returned to EVGA for repair.  It is possible, though unlikely, that 
it returned a refurbished card with a few problems.  Motherboard
manufacturers do that all the time.  I downloaded a program named
GPU_Caps_Viewer_1.21.1.4 and ran it.  It says the two cards are
identical, but there is no way to tell for sure if that program 
is table-driven or actually reading values.

In any case, either GPU Caps Viewer or Boinc is wrong.

If anyone has any ideas on how to determine the actual
device capabilities, I would love to hear about it.

Charles Elliott


> -----Original Message-----
> From: boinc_dev [mailto:[email protected]] On Behalf
> Of Jacob Klein
> Sent: Thursday, October 2, 2014 2:30 PM
> To: McLeod John; Eric Korpela
> Cc: BOINC Development
> Subject: Re: [boinc_dev] BOINCscheduling & plan class possible issue
> 
> Yes. Unfortunate.
> 
> Back when my setup consisted of [GTX 660 Ti + GTX 460 + GTS 240] ...
> it was trial and error to see which applications would simply fail hard
> on that GTS 240. After the trial and error, I was able to build a
> pretty good <exclude_gpu> list in my cc_config.xml, such that I'd be
> able to prevent the failures. And David helped me also by fixing up
> client work fetch behaviors, to better handle all of my <exclude_gpu>
> entries.
> 
> Now, my setup is [GTX 660 Ti + GTX 660 Ti + GTX 460]. All applications
> from my GPU projects appear to work correctly on any of the GPUs, and I
> don't need to use <exclude_gpu> anymore.
> 
> For the current design, for the server, it sounds like you just send
> tasks (as appropriately as you can, based on the GPU type the client
> sent), and if they fail on the lesser GPUs, they fail. Not much can be
> done.
> 
> For a better design, the BOINC client needs to inform the server of the
> models and capabilities, of each GPU, and possibly have the scheduler
> indicate which tasks can run on which GPUs.
> 
> Recommending not to use <use_all_gpus>... was a bit silly-sounding.
> However, since this problem only happens when the user uses that flag,
> then hopefully they are competent enough to also set up <exclude_gpu>
> entries as needed, to accommodate this design deficiency.
> 
> Regards,
> Jacob
> 
> 
> 
> 
> > From: [email protected]
> > To: [email protected]
> > Date: Thu, 2 Oct 2014 16:06:12 +0000
> > CC: [email protected]
> > Subject: Re: [boinc_dev] BOINCscheduling & plan class possible issue
> >
> > That is unfortunate.
> >
> > Sent from my Android phone using TouchDown (www.nitrodesk.com)
> >
> > -----Original Message-----
> > From: Eric J Korpela [[email protected]]
> > Received: Thursday, 02 Oct 2014, 12:04PM
> > To: McLeod, John [[email protected]]
> > CC: [email protected] [[email protected]];
> [email protected] [[email protected]]
> > Subject: Re: [boinc_dev] BOINCscheduling & plan class possible issue
> >
> > The project is only informed about the most capable devices and the
> total number of GPUs.
> >
> > On Thu, Oct 2, 2014 at 8:59 AM, McLeod, John
> <[email protected]<mailto:[email protected]>> wrote:
> > Can the project send work that will run on the least capable device
> and have it run on both?
> >
> > Sent from my Android phone using TouchDown
> (www.nitrodesk.com<http://www.nitrodesk.com>)
> >
> > -----Original Message-----
> > From: Raistmer the Sorcerer
> [[email protected]<mailto:[email protected]>]
> > Received: Thursday, 02 Oct 2014, 11:47AM
> > To: [email protected]<mailto:[email protected]>
> [[email protected]<mailto:[email protected]>]
> > Subject: Re: [boinc_dev] BOINCscheduling & plan class possible issue
> >
> > This solution requires user intervention. The question is how to
> avoid this server-side. User can be not aware that his host generates
> invalid result and project can't prevent it now.
> >
> >
> > Thu, 02 Oct 2014 17:06:05 +0200 от David Anderson
> <[email protected]<mailto:[email protected]>>:
> > >Yes.
> > >You can also use <exclude_gpu> to be more specific
> > >about which GPU to use for which project.
> > >
> > >On 02-Oct-2014 4:59 PM, McLeod, John wrote:
> > >> Would that then prevent BOINC from running tasks on some of the
> GPS for any tasks?
> > >>
> > >> Sent from my Android phone using TouchDown (
> www.nitrodesk.com<http://www.nitrodesk.com><http://www.nitrodesk.com> )
> > >>
> > >> -----Original Message-----
> > >> *From:* David Anderson
> [[email protected]<mailto:[email protected]>]
> > >> *Received:* Thursday, 02 Oct 2014, 10:58AM
> > >> *To:*
> [email protected]<mailto:[email protected]>
> [[email protected]<mailto:[email protected]>]
> > >> *Subject:* Re: [boinc_dev] BOINCscheduling & plan class possible
> issue
> > >>
> > >> I assume these are cases where the user has set <use_all_gpus>.
> > >> If that flag is removed the problem should go away.
> > >> -- David
> > >>
> > >> On 02-Oct-2014 4:28 PM, Raistmer the Sorcerer wrote:
> > >>> It was discovered that OpenCL AstroPulse application in SETI
> can't properly work
> > >>> under 340.52 nVidia driver on pre-FERMI hardware (single pulses
> missing, issue
> > >>> reported and reproduced by NV already). To avoid wrong
> computations Eric created
> > >>> 2 plan classes that should avoid work sending on pre-FERMI GPUs
> running under
> > >>> that faulty driver.
> > >>>
> > >>> But it was discovered (look here:
> > >>>
> http://setiweb.ssl.berkeley.edu/beta/forum_thread.php?id=2182&postid=52
> 632 )
> > >>> that multi-GPU hosts containing both FERMI and pre-FERMI GPUs are
> able to recive
> > >>> tasks under another common plan class for FERMI devices and
> execute those recived
> > >>> tasks on pre-FERMI devices. That is, though server obey plan
> class and ignore
> > >>> pre-FERMI devices on 340.52 driver, BOINC client doesn't obey
> plan class and
> > >>> schedule to run tasks for FERMI devices on pre-FERMI ones (when
> both present in
> > >>> host).
> > >>>
> > >>> Could someone confirm this issue? And how one should act to
> exclude pre-FERMI
> > >>> devices on 340.52 driver in such case of mixed NV devices in
> host?
> > >>>
> > >>>
> > >>>
> > >> _______________________________________________
> > >> boinc_dev mailing list
> > >>  [email protected]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[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.

_______________________________________________
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.

Reply via email to