Would it be reasonable to ask the BOINC developers to add code to report more details about what specific type of chip the GPU board uses, in order to help gather more information about which GTX260 boards work with GPUGRID? Or would it be more reasonable to add such code to your application instead, so that even most failed workunits would be able to send back such information?

Also, since the GTX260 boards work better with the CUDA 2.1 drivers, would it be reasonable to try a GTX260-specific version of the application that was compiled using the CUDA 2.1 SDK, but without many other changes? If such a version works well, you could even make the same application available for some of any other Nvidia boards that work well with CUDA 2.1 drivers, but not with the more recent drivers.

An idea to consider to eliminate some of the separate queues: Put more than one version of the application code into each workunit, along with a program that does little more than select which of the application versions to use.

I think that in the long term it will be essential for most projects to be able to better determine hardware and allocate tasks accordingly.
It makes sense that the Boinc developers do this, rather than have each individual project try to write their own code. However, they have not done this yet.
So problems like this one remain serious issues for some projects.

If all the required information is not available (core version), perhaps a crude method of task allocation would be to base it on Boinc calculated GFlops ratings (the 65nm GT200 cards Gflops may be distinguishable from the rest):
There are 3 distinct bands of real world Boinc ratings for the GTX 260. Fortunately none of these cards reach the performance of the GTX 275 and all are noticeably better than Cuda Capable 1.1 cards.
The 9800x2 is viewed as two distinct cards, each with a lesser rating than a GTX 260 sp192.
Although the GTX 260 sp216 GT200b looks as though it might be an issue with the GTX 295, as these are seen as two individual cards with only slightly better performance than the 55nm GTX 260, there is not a task problem with the GTX 260 sp216 GT200b version – so you would only need to isolate the other 2 cards.

The 3 distinct versions of the GeForce GTX 260:
The sp192 using a 65nm GT200 core
The sp216 using a 65nm GT200 core
The sp216 using a 55nm GT200b core
The problem cards use the 65nm GT200 rather than the 55nm GT200b core architecture.

Aside - The industry published default GFlops ratings are 715, 805 and 874 respectively and the TDP values are 182, 182, 171 respectively.
In reality these vary by up to about 20% due to factory overclocking of the core, shaders &/or memory. Due to the smaller, 55nm, core the sp216 GT200b cards tend to be clocked higher and therefore offer greater performance (distinct from the GT200).

I would say that the isolation range would roughly be between, 480 Boinc GFlops and 505 Boinc GFlops (to identify the 65nm GT200 cores).
Just above the top GeForce 9800 GTX+ and GTS 250 (475 Boinc GFlops), and just below the tamer GTX 260 55nm GT200 (510 Boinc GFlops).
Of course you could err on the side of caution, as the tasks would still run well presumably?

I still got 80 percent errors on my 260s. Maybe the developers should have a quiet talk with the guys from collatz? After wasting some time here i am again back to collatz. Will check again in 30 days.

regards

Change your project application preferences, you are using the old application, as I was!

Goto Your account, select GPUGrid Preferences, Select Edit GPUGrid Prefernces, and Deselect ACEMD - leaving ACEMD 2 (the new application).

http://www.gpugrid.net/prefs.php?subset=project

The problem with CUDA FFT on some 260 cards is still there. The new application does not solve it. We are working on eliminating the CUDAFFT all together.

gdf

If the ACEMD 2 project runs 60% faster then there would be less chance of any error for any given task. Therefore any given task is more likely to complete and overall more work will be done by users that experience FFT errors.

It would not matter if you GTX260 works, then it will also work with the second application. It is just more work for us, that we need to maintain two queues.

gdf

An alternate plan to consider: put both application programs in each workunit, along with a script to choose which one of them to actually use. If the 260-only program can still handle all workunits, that should eliminate the second queue.

A questionable idea if the 260-only application gives enough difference in outputs, though.

Does new 6.15 beta application for Linux solve the bug?

---

From Siberia with love!

Any progress on the GTX 260 issue? Resolved? Still working on it? Not going to be fixed?

As far as I know there has been no progress on this front at GPUGrid, however there is another application in the final stages of development, 6.72; it is possible that this may resolve some of the issues crunching with the older 65nm versions of the GTX 260 (effects the older GT200 cards, but not the newer GT200b).

On a positive note, the latest recommended Boinc versions (6.10.43) do facilitate GPU crunching stability much more effectively. My take on this (which might be wrong) is that if a GPU task fails, it tries to pick up at the tasks last restore point (a few minutes in the past) and starts from there again.
So, I would suggest you upgrade to the latest Boinc release and run some of the present tasks 6.03. As these run in about 6h for a GTX 260 their shorter time period offers better chances of completion. Note, any Long Tasks have “long” in their name!
At the minute I am mostly picking up these shorter tasks, the ones you should try first.

If you get a reasonable success rate with these tasks, then start crunching again. If not come back in a few days and check if the 6.72 app has been released, choose to only run that app, and have another go.

Good luck,

Nvidia told us that the problem is solved with CUDA3, but we did not check it.

gdf

Nvidia told us that the problem is solved with CUDA3, but we did not check it.

gdf

I have checked it, 6.72 tasks erroed out even on the underclocked one. Time to time a short test task finished OK.
Host ID 31329.

That's delivering cuda3 only to Fermi cards.
gdf

Sorry, short test 3.0 tasks you have sent to GTX260 a weeks ago are deleted. I haven´t noticed it. Thanks for explaining of using 3.0 for Fermi cards only.

so is this problem fixed yet? i have two gtx260's, one is working fine, the other one is a 65nm core216 and doesn't work. please let me know if there's hope in holding on to this card for a future fix, or if i should just sell this card because there won't be any plans to problem.

Sorry, short test 3.0 tasks you have sent to GTX260 a weeks ago are deleted. I haven´t noticed it. Thanks for explaining of using 3.0 for Fermi cards only.

The reason is that Fermi require 3.0 tasks, while for other cards the code compiled with 3.0 is slower.
I can change the server to deliver also to GTX260.

gdf

The reason is that Fermi require 3.0 tasks, while for other cards the code compiled with 3.0 is slower.
I can change the server to deliver also to GTX260.

gdf[/quote]

Yes please, better a bit too slow than nothing at all.

kind regards

Alain

This will be interesting!

You might want to make it clear what to select here,
ACEMD: ACEMD ver 2.0: ACEMD beta:

The reason is that Fermi require 3.0 tasks, while for other cards the code compiled with 3.0 is slower.
I can change the server to deliver also to GTX260.

gdf

Hopefully that won't send the slower code to all the good GTX 260 cards too. Slowing them all down to fix just a few is not so good. You could possibly make a new choice in preferences with a different queue:

ACEMD: no
ACEMD ver 2.0: no
ACEMD beta: no
GTX260/65nm only: yes

or

ACEMD: no
ACEMD ver 2.0: no
ACEMD beta: no
Fermi / GTX260/65nm only: yes

so are these updated to accept fermi WU's yet?