gtx460, 35,820 secs (average) per wu (9.95 hours). My GTX295's are around 10 hours a wu

Hmm ok.. now i only have one WU to compare with and i had it stopped once..

It took 10h 41min on the 460..

My GTX 275 card made the last 2 WU in
9h 16 min and 6h (?)

So far the GTX 275 seems faster for this project too...

Lots of posts about this in the Forums and your observations tally well with others.
The GTX275 has been faster than the GTX460 since the release of the GTX460. In fact a GTX260-216 was slightly faster, about 5% at reference clock speeds. Why? Poor support by NVidia; basically the card is not well utilized and this comes down to the applications and drivers. On the one hand NVidia go on about their new design and all those Cuda cores, on the other they don’t give you the drivers to use them. Personally I think this is a deliberate ploy to reduce RTM’s. It’s like getting a car with a 2year warranty only to find it won’t go over 45mph for 2years.
Over the last week the GPUGrid techs started playing with different apps, so now if your GTX275 has a recent driver it will probably not be running the fast CUDA 2.2 app and will instead be using a CUDA 3.1 app, designed for Fermis and not G200 series cards. How individual cards performs on these is open to debate, but in particular the GT240s took a big hit in performance running the CUDA3.1 app, and the latest drivers resulted in many cards dropping their clocks.
To get the older app (for non-Fermi’s) you need to use older drivers, which for some means their system will not detect multiple cards and they have to use cables and omni ports or dummy plugs. Even the use of the Beta 25715 driver will get you CUDA3.1 tasks, so you will need to use a driver from before that.
We are now in a position where many people are running the wrong app. By the end of the month we may be running Cuda 3.2 apps on Fermis so there is not too much point trying to compare the cards right now. It was always expected that the CUDA 3.2 driver will bring a performance gain to the GTX460. Should no performance gain for the GTX460 be found I would write that entire range of Fermi’s off as failures. With the present drivers and app if a GTX475 turned up today it would not outperform a 20month old GTX275 at reference.

Personally I think this is a deliberate ploy to reduce RTM’s.

I think you're reading too much into this. It's probably much more a matter of "can't get it to work properly" than "don't want it to work properly". Last quarter AMD had surpassed nVidia as the (non-Intel) GPU king and they've taken a lot of flak for the Fermi design. Plus the issue of non-existent GT200 mainstream chips for a very long time and the notebook chips recalls.

They just can't afford to make their cards perform worse deliberately.

MrS

---

Scanning for our furry friends since Jan 2002

Over the last week the GPUGrid techs started playing with different apps, so now if your GTX275 has a recent driver it will probably not be running the fast CUDA 2.2 app and will instead be using a CUDA 3.1 app, designed for Fermis and not G200 series cards. How individual cards performs on these is open to debate, but in particular the GT240s took a big hit in performance running the CUDA3.1 app, and the latest drivers resulted in many cards dropping their clocks.
To get the older app (for non-Fermi’s) you need to use older drivers, which for some means their system will not detect multiple cards and they have to use cables and omni ports or dummy plugs. Even the use of the Beta 25715 driver will get you CUDA3.1 tasks, so you will need to use a driver from before that.
We are now in a position where many people are running the wrong app. By the end of the month we may be running Cuda 3.2 apps on Fermis so there is not too much point trying to compare the cards right now. It was always expected that the CUDA 3.2 driver will bring a performance gain to the GTX460. Should no performance gain for the GTX460 be found I would write that entire range of Fermi’s off as failures. With the present drivers and app if a GTX475 turned up today it would not outperform a 20month old GTX275 at reference.

This begs the question, why do we keep switching to apps that are slower and don't work well for many cards? I now have had enough WUs to make similar WU comparisons between 6.05 and the new 6.12 on various cards. I'm seeing a 5% to occasionally as much as a 20%(rare) slowdown with 6.12. Is there any advantage to 6.12 that made them replace the faster 6.05? Why do we keep getting new apps that seem to be inadequately tested? Is there any reason not to return to 6.05?

From a crunchers point of view 6.05 was better.
There are probably server side / ACEMD reasons to using 6.12 (maintaining queues, databases) but I am not fully aware of them. Might be a move to allow for CUDA3.2 in the near future, and a licence issue, but then we dont know for sure that CUDA3.2 will be a success. If, and I speculate, we move to CUDA3.2 to allow for the next round of Fermi cards then we might not also be able to have 3.1 and 3.0 and so on. I guess this might also be due to task creation, hard drive limitations on the server (they need more), and general project management, but I don’t have many details.

From a crunchers point of view 6.05 was better.
There are probably server side / ACEMD reasons to using 6.12 (maintaining queues, databases) but I am not fully aware of them.

It would be a really good idea to communicate reasons for changes if there are reasons. From the posts it looks like the Linux crunchers are taking even a bigger hit than those of us running Windows. Lately though we've had to revert to older drivers to avoid 6.11 and get back to 6.05, then as soon as we do that we get the slower running 6.12. To get get rid of that it sounds like we're going to have to use an app_info.xml. Is it OK to do that? Who knows? What was the problem if any with 6.05?

As said in another post we are looking into it.
A solution should come out next week.

gdf

As said in another post we are looking into it.
A solution should come out next week.

gdf

And in the meantime, should we waste our precious GPU time on the rubbish 6.12? It's absolutely uncrunchable on a Linux machine. If you don't put back the working version I will think about it as willful neglect. There is absolutely no reason to punish the Linux machine with that crap! It's not about 10% slower, it's about 1000% slower. That's plain ridiculous.

---

Gruesse vom Saenger

For questions about Boinc look in the BOINC-Wiki

The reason because on Linux is slower than before is that now it does not use SWAN_SYNC=0 by default. So now it uses less CPU. I don't think that it's useful but it was a requested more and more times. Just set
export SWAN_SYNC=0
in your .bashrc


gdf

Just set
export SWAN_SYNC=0
in your .bashrc

As I've said in some other post: I'm no programmer, I'm a user.
In what GUI do I do that?
What's the .bashhrc?
How will that influence other programs and projects?

---

Gruesse vom Saenger

For questions about Boinc look in the BOINC-Wiki

How will that influence other programs and projects?

Oh the joys of linux. Sorry, can't tell you how to do it but it certainly doesn't influence other software. As long as noone else chooses to call his environment variable "SWAN_SYNC".

MrS

---

Scanning for our furry friends since Jan 2002

I don’t presently have a Linux system to try this on, and I am no Linux expert either, but I guess you just have to open up a command terminal and type in,
.bashrc export swan_sync=0

.bashrc configures interactive Bash usage.
The term “Export” is used to set an environmental variable.
So, .bashrc export configures an interactive environmental variable.

I think -n is used to stop it.

you have to edit the file .bashrc and add the line export SWAN_SYNC=0.

gdf

you have to edit the file .bashrc and add the line export SWAN_SYNC=0.

gdf

Where is this file?

Edith says:
I found 4 different ones in different places, 2 dot.bashrc, 2 bash.bashrc

---

Gruesse vom Saenger

For questions about Boinc look in the BOINC-Wiki

The file it's in your home directory, but as it starts with a dot, it's hidden.
Just edit it gedit .bashrc

gdf

The file it's in your home directory, but as it starts with a dot, it's hidden.
Just edit it gedit .bashrc

gdf

There ain't anything like that.
And of course I've set the Nautilus to "Show Hidden Files".
The only file with "bash" in it is .bash_history.

---

Gruesse vom Saenger

For questions about Boinc look in the BOINC-Wiki

Just create it then.

gdf

Just create it then.

gdf

What's it supposed to do?
Why should I create a hidden file in my main folder outside BOINC for your project?
Why don't you include it in your program?
What will other applications outside BOINC do with this?

---

Gruesse vom Saenger

For questions about Boinc look in the BOINC-Wiki

Don't do anything then. There will another way of doing sometime soon within your BOINC dir.

gdf

Just create it then.

gdf

What's it supposed to do?
Why should I create a hidden file in my main folder outside BOINC for your project?
Why don't you include it in your program?
What will other applications outside BOINC do with this?