if someone buy one please share with us the test results, i'm considering of buying one or GTX 690. Thanks

If I were to choose between 690 and Titan I'd go with Titan for SETI purposes. Titan is geared more towards computation while 690 scores better for gaming.

But they are both very pricey and keeping either one fed with work would be a pain. I'm not sure it's worth it.

http://www.overclockers.co.uk/productlist.php?groupid=701&catid=1914&subid=1576&sortby=priceDesc

Gigabyte eta on there is the 27th Feb so later today

Asus is 28th

Both EVGA 15th March

OCUK H2O version just says for preorder

I wish I had enough to just blow some money on 1 or 2...

---

if someone buy one please share with us the test results, i'm considering of buying one or GTX 690. Thanks

If I were to choose between 690 and Titan I'd go with Titan for SETI purposes. Titan is geared more towards computation while 690 scores better for gaming.

But they are both very pricey and keeping either one fed with work would be a pain. I'm not sure it's worth it.

A Titan would turn around any individual work unit faster than a 690, but in terms of work units over time the 690 would crunch more (at least according to the numbers I've seen so far). GPU for GPU the Titan is faster but the 690 should win on throughput because of 2 GPUs with each being maybe 70% of a Titan GPU.

Keeping either one of them fed would be challenging.

---

Keeping either one of them fed would be challenging.

I agree 100%, I can´t even keep my 690 feeded, imagine a 2x780 host...

---

The Titan is available here for around $1035 including shipping and delivery. Not really sure if I want to get one of these, even if I had the money right now, given the status of work availability. Saw this video on youtube, an hour and a half long review of the card.
______________

If anybody here gets a chance to test a Titan card, no matter how briefly, could they please check whether:

1) It still errors out all tasks run with the stock v6.10 'fermi' application
2) The 'CUDA_GRID_SIZE_COMPAT' environment variable workround still makes the stock app work again

Thanks.

If anybody here gets a chance to test a Titan card, no matter how briefly, could they please check whether:

1) It still errors out all tasks run with the stock v6.10 'fermi' application
2) The 'CUDA_GRID_SIZE_COMPAT' environment variable workround still makes the stock app work again

Thanks.

Hi Richard,

I just took delivery of a Titan a couple of days ago and have it running. I'm using the 314.09 NVidia driver which is the launch driver for the Titan. As far as I know, this driver only works in the Titan, but EVGA tells me that an updated driver is on the way which will allow you to mix Titans and other NVidia GPUs in the same machine.

I just removed this environment variable from the machine. It's a leftover from when I had a 690 in this machine. I believe that one of the 310.90 versions removed the need to have this environment variable.

As for the stock 6.10 app, I don't even know where to get it. I'm running the optimized ZC version with Cuda 5.0. If you know where I can get the original stock app, I'll be glad to try it for you.

---

I just removed this environment variable from the machine. It's a leftover from when I had a 690 in this machine. I believe that one of the 310.90 versions removed the need to have this environment variable.

May I ask where you got that belief from? I was prompted to ask for the test by a message posted on another board by the owner of host 6922055 - that machine is running driver 310.90, and so far has trashed every cuda task in a way consistent with a missing environment variable. (I've drawn their attention to the sticky thread about workrounds, but I don't think they've been back to read the reply to their post yet)

As for the stock 6.10 app, I don't even know where to get it. I'm running the optimized ZC version with Cuda 5.0. If you know where I can get the original stock app, I'll be glad to try it for you.

If you wouldn't mind testing, I'll put together a package with the stock app, matching DLLs, and app_info stub - I'll PM you a with a download location a little later, when I've had time to make sure I've done it right.

I just removed this environment variable from the machine. It's a leftover from when I had a 690 in this machine. I believe that one of the 310.90 versions removed the need to have this environment variable.

May I ask where you got that belief from? I was prompted to ask for the test by a message posted on another board by the owner of host 6922055 - that machine is running driver 310.90, and so far has trashed every cuda task in a way consistent with a missing environment variable. (I've drawn their attention to the sticky thread about workrounds, but I don't think they've been back to read the reply to their post yet)

As for the stock 6.10 app, I don't even know where to get it. I'm running the optimized ZC version with Cuda 5.0. If you know where I can get the original stock app, I'll be glad to try it for you.

If you wouldn't mind testing, I'll put together a package with the stock app, matching DLLs, and app_info stub - I'll PM you a with a download location a little later, when I've had time to make sure I've done it right.

Richard, maybe I'm a little mixed up but I've read so many posts and threads about this that I may very well be wrong.

Anyway if you have a way of getting me a package of files for this app, I'll test it for you. I've got to be careful since I have a heavily modified app_info file and don't want to trash the existing work units.

Thanks

---

Anyway if you have a way of getting me a package of files for this app, I'll test it for you. I've got to be careful since I have a heavily modified app_info file and don't want to trash the existing work units.

Thanks

PM sent.

Looking at the host
GTX590 / Titan
433,50 / 527,20
x41g / x41zc, Cuda 5.00
wuid=1179732154
how many wu's at once they run ? once ?

if so, results are not so impressed as I thought

_heinz

GTX470 / Titan
656,09 / 536,20
wuid=1179622789
looks like titan did not use its full resources....

_heinz

OK guys, I ran some work units through the Titan to get some meaningful stats. Here's what I came up with.

Scenario 1 - 1 task only.

http://setiathome.berkeley.edu/result.php?resultid=2856244593

CPU time - 100.76, Run time - 338.33, AR - .383, credit - 111.64

Scenario 2 - 2 tasks at one time - both started at same time and finished within several seconds of each other.

http://setiathome.berkeley.edu/result.php?resultid=2856244675
http://setiathome.berkeley.edu/result.php?resultid=2856244481

CPU time - 121.57, Run time - 513.60, AR - .383 - no credit yet
CPU time - 122.62, Run time - 516.66, AR - .383 - credit - 141.85

At some point, I'll run 3 at a time but based on testing with Fred's tool you only gain a few more percent going to 3. I found this to be true on the 690s also. Going from 1 to 2 gains you 30% to 35% more throughput.

Now, APs are another topic that I need to get some better information on.

Edit: BTW, I ran this with x41zc and Cuda 5.0.

---

what is your Gpu % rate of utilisation when running 2 wu at once?

---

Added some to my christmas wishes.

---

setiathome_CUDA: CUDA Device 1 specified, checking...
Device 1: GeForce GTX TITAN is okay
SETI@home using CUDA accelerated device GeForce GTX TITAN
pulsefind: blocks per SM 4 (Fermi or newer default)
pulsefind: periods per launch 100 (default)
Priority of process set to BELOW_NORMAL (default) successfully

Some suggested settings to see if it has some 'legs', would be at least 2 tasks at a time (preferably 3 or 4, for latency hiding purposes), and the following entries in mbcuda.cfg :

[mbcuda]
processpriority = abovenormal
pfblockspersm = 15 ; maybe even 16, which is the max at the moment
pfperiodsperlaunch = 200 ; maybe more...

---

"Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions.

setiathome_CUDA: CUDA Device 1 specified, checking...
Device 1: GeForce GTX TITAN is okay
SETI@home using CUDA accelerated device GeForce GTX TITAN
pulsefind: blocks per SM 4 (Fermi or newer default)
pulsefind: periods per launch 100 (default)
Priority of process set to BELOW_NORMAL (default) successfully

Some suggested settings to see if it has some 'legs', would be at least 2 tasks at a time (preferably 3 or 4, for latency hiding purposes), and the following entries in mbcuda.cfg :

[mbcuda]
processpriority = abovenormal
pfblockspersm = 15 ; maybe even 16, which is the max at the moment
pfperiodsperlaunch = 200 ; maybe more...

Thanks Jason for these suggestions.

I experimented during the last few hours with varying some of these parameters using Fred's SetiPerf program. Running anywhere from 1 to 4 concurrent tasks resulted in little if any improvement. I know these changed parameters where being picked up by SetiPerf since I saw the change in process priority to above normal in task manager.

And to a previous poster, with a single task running Precision X 4.0.0 shows 57% GPU usage. With 2 tasks, usage goes to 86% with spikes to 95%. 3 tasks puts usage at 98% and it stays there.

One thing I should point out is that the machine the Titan is in at present is a Dell T7400 workstation. It's 5 years old and only has PCIe 2.0 slots. I don't think that makes much difference to Seti, but I'm not sure of any performance impacts. Eventually this GPU will be in a 3.0 machine.

The problem I really got now is with AP. I keep getting the AP tasks to run a few seconds and then restart. They keep doing this until I suspend them. It keeps telling me to reset the project which I already did once and thinking about doing again - I have little faith that this will do any good. MB runs just fine on Titan. A couple of days ago I did get a few AP WU through, but don't know what happened. I have tried different versions including 1761 and 1766.

I'm almost ready to install Seti@home from scratch and then recustomize the app_info. This has really got me scratching my head. If anybody out there has any ideas, I'm all ears.

Edit: I should have mentioned that it appears that the AP work unit exits with a zero status. It also says that "...exited with zero status but no 'finished' file" What is a finished file?

---

...
It keeps telling me to reset the project which I already did once and thinking about doing again - I have little faith that this will do any good.
...

That advice is completely useless when running anonymous platform. Even for stock where it gets fresh copies of the applications it is usually not the right thing to do, corrupted applications are rare.

                                                                    Joe

...
It keeps telling me to reset the project which I already did once and thinking about doing again - I have little faith that this will do any good.
...

That advice is completely useless when running anonymous platform. Even for stock where it gets fresh copies of the applications it is usually not the right thing to do, corrupted applications are rare.

                                                                    Joe

Thanks Josef, that's what I was thinking. Do you know what a 'finished file' is? I'm trying to figure out how to troubleshoot this.

---

...
Do you know what a 'finished file' is? I'm trying to figure out how to troubleshoot this.

When an application finishes a task and exits normally, it creates an empty file named boinc_finish_called. If that's not present the BOINC client will restart the task, expecting the application to restart from its last checkpoint.

For your AP tasks which you've aborted after going through several of those cycles, some have the stderr.txt produced by the application showing

ERROR: clEnqueueNDRangeKernel: GPU_coadd_kernel_cl: -4

I don't know what the -4 error indicates. Raistmer would.

                                                                  Joe