GTX 460 superclocked

[TouchuvGrey]

Downloaded and installed Lunatics_Win64v0.37_(SSE3+)_AP505r409_AKv8bx64_Cudax32f.exe
( Beta ) hoping this will help. i've watched my host average drop from 13,500 per day to
8700 per day since installing the GTX460. Suspecting i screwed something up along the way.
i have a Black Belt in that sort of thing. <sigh>

[Jason G]

Cheers!  Yeah should help a fair bit straight away ~20% maybe.  It's still early days with those cards.  no Cuda documentation mentioning them, and only one introductory driver out. Rest assured they seem to be a very popular card, and will start to grab a foothold.

Jason

[Josef W. Segur]

Downloaded and installed Lunatics_Win64v0.37_(SSE3+)_AP505r409_AKv8bx64_Cudax32f.exe
( Beta ) hoping this will help. i've watched my host average drop from 13,500 per day to
8700 per day since installing the GTX460. Suspecting i screwed something up along the way.
i have a Black Belt in that sort of thing. <sigh>

Actually, we screwed up. We failed to make it clear that all S@H CUDA applications built before the Fermi cards were released have problems on those cards, so you were running the v12 application and turning in a lot of tasks with a false result_overflow. Many of those ended up being judged invalid so got no credits. Some also happened to be paired with another host also running old CUDA code on Fermi, those unfortunately get validated and assimilated into the database. However, they overflow so quickly that there are few credits granted even for those.

There may be a lingering problem because the DCF has adapted to doing a lot of the work in extremely short time. That could lead to BOINC killing some tasks for "exceeded elapsed time limit", the infamous -177 error. The new rescheduler Fred M made has an expert feature to prevent any possibility of that, and IIRC there's a way to use that feature without actually rescheduling tasks. I hope someone who has actually used that will post a quick clear procedure. I don't have any GPU capable of crunching, so am only going on what I've read elsewhere.

You might also want to reduce your cache settings before asking for work during the uptime beginning Friday, the system thinking your GTX460 is much faster than it really is could lead to getting more work than you really want. After the host has 50 or so validated tasks done with x32f the server average should be close enough to not worry about that much, so the cache can be made as large as you need before the next outage.
                                                                                       Joe

[SciManStev]

On the expert tab, there is a check box that says Limit rsc_fpops_bound to avoid -177 errors. Check that off, and go to the first tab and push run. It takes a few seconds, but it works perfectly. I stopped a bunch of -177 errors cold by running that. Make sure you are not in simulation mode, which is also on the expert tab.

Steve

[Richard Haselgrove]

Actually, we screwed up. We failed to make it clear that all S@H CUDA applications built before the Fermi cards were released have problems on those cards, so you were running the v12 application and turning in a lot of tasks with a false result_overflow. Many of those ended up being judged invalid so got no credits. Some also happened to be paired with another host also running old CUDA code on Fermi, those unfortunately get validated and assimilated into the database. However, they overflow so quickly that there are few credits granted even for those.
                                                                                       Joe

Well, we were slow to pick up, but we were there by early June: I thnink all the warnings were in place by

http://lunatics.kwsn.net/1-discussion-forum/when-corrupted-results-get-validated.msg27734.html#msg27734
http://lunatics.kwsn.net/gpu-crunching/unified-installer-with-fermi-support.msg27926.html#msg27926

Anybody who installed any v12 or other non-Fermi app after then, with all the warnings here and on the main project, just wasn't reading. And of course, from that point onwards, just allowing stock download would have worked.

[TouchuvGrey]

Downloaded and installed Lunatics_Win64v0.37_(SSE3+)_AP505r409_AKv8bx64_Cudax32f.exe
( Beta ) hoping this will help. i've watched my host average drop from 13,500 per day to
8700 per day since installing the GTX460. Suspecting i screwed something up along the way.
i have a Black Belt in that sort of thing. <sigh>

Actually, we screwed up. We failed to make it clear that all S@H CUDA applications built before the Fermi cards were released have problems on those cards, so you were running the v12 application and turning in a lot of tasks with a false result_overflow. Many of those ended up being judged invalid so got no credits. Some also happened to be paired with another host also running old CUDA code on Fermi, those unfortunately get validated and assimilated into the database. However, they overflow so quickly that there are few credits granted even for those.

There may be a lingering problem because the DCF has adapted to doing a lot of the work in extremely short time. That could lead to BOINC killing some tasks for "exceeded elapsed time limit", the infamous -177 error. The new rescheduler Fred M made has an expert feature to prevent any possibility of that, and IIRC there's a way to use that feature without actually rescheduling tasks. I hope someone who has actually used that will post a quick clear procedure. I don't have any GPU capable of crunching, so am only going on what I've read elsewhere.

You might also want to reduce your cache settings before asking for work during the uptime beginning Friday, the system thinking your GTX460 is much faster than it really is could lead to getting more work than you really want. After the host has 50 or so validated tasks done with x32f the server average should be close enough to not worry about that much, so the cache can be made as large as you need before the next outage.
                                                                                       Joe

    Thank you Joe:

                 That explains quite a bit i was puzzled by. i'm very looking forward to
using an app that can take full advantage of the Fermi series. When they become
available i just may have to get a 2nd 460 for Aiden ( my main rig, named for my
newest grandson ).
         i need clear and simple procedures for modifying config files and applications.
If there is any ambiguity at all in the instructions i will choose the wrong way of
doing something far more often than random chance would seem to allow.  

[TouchuvGrey]

On the expert tab, there is a check box that says Limit rsc_fpops_bound to avoid -177 errors. Check that off, and go to the first tab and push run. It takes a few seconds, but it works perfectly. I stopped a bunch of -177 errors cold by running that. Make sure you are not in simulation mode, which is also on the expert tab.

Steve

 i just looked and failed to find the expert tab which tells me i'm looking in the wrong
place or i don't have one. Where do i look or how do i get one ?

   To Richard who said "Anybody who installed any v12 or other non-Fermi app after then, with all the warnings here and on the main project, just wasn't reading...."

     i plead guilty as charged, i have a long history of not reading the instructions.

[perryjay]

You are using Fred's (Efmer) 2.0 rescheduler aren't you? If you are, just look along the top, the expert tab is the last one on the right.

i plead guilty as charged, i have a long history of not reading the instructions.

 I read them it's just that they might as well be in Greek most of the time. I need a lot of hand holding on these things.   

[TouchuvGrey]

You are using Fred's (Efmer) 2.0 rescheduler aren't you? If you are, just look along the top, the expert tab is the last one on the right.

i plead guilty as charged, i have a long history of not reading the instructions.

 I read them it's just that they might as well be in Greek most of the time. I need a lot of hand holding on these things.   

     It sounds like i need to be using that rescheduler, where do i get it and how and where do i install it ?
A lot of this is Greek to me too, but what little i can get from it is a liitle that i did not know before.

[Josef W. Segur]

Actually, we screwed up. We failed to make it clear that all S@H CUDA applications built before the Fermi cards were released have problems on those cards
...
                                                                                       Joe

Well, we were slow to pick up, but we were there by early June: I thnink all the warnings were in place by

http://lunatics.kwsn.net/1-discussion-forum/when-corrupted-results-get-validated.msg27734.html#msg27734
http://lunatics.kwsn.net/gpu-crunching/unified-installer-with-fermi-support.msg27926.html#msg27926

Anybody who installed any v12 or other non-Fermi app after then, with all the warnings here and on the main project, just wasn't reading. And of course, from that point onwards, just allowing stock download would have worked.

Agreed, anyone who read and remembered the 19th reply in the first thread you mentioned should not have gotten into difficulties. The second thread is in the section of this site closed to all except developers and alpha testers, so TouchuvGrey will not have seen that. In retrospect, your proactive approach suggested there was a very good idea and I hereby declare you not a part of the "we" who screwed up. And of course your warnings on the main project, etc. were very helpful. So much so that I for one didn't realize until quite recently that the smoldering embers were threatening to turn into a full blown fire.

Basically, the difficulty is we developers and many others here have a very technical orientation. What is obvious to us is not necessarily so for our users, and we failed to communicate effectively across that gap. Even a clear statement on the front page and in the description of the 0.36 downloads that V12 isn't Fermi compatible would not have completely prevented the developing problem, many are buying Fermi cards as an upgrade and no reinstall seems necessary in such cases. I'd be more comfortable if we had at least tried that kind of warning, though.
                                                                                      Joe

[Josef W. Segur]

You are using Fred's (Efmer) 2.0 rescheduler aren't you? If you are, just look along the top, the expert tab is the last one on the right.

i plead guilty as charged, i have a long history of not reading the instructions.

 I read them it's just that they might as well be in Greek most of the time. I need a lot of hand holding on these things.   

     It sounds like i need to be using that rescheduler, where do i get it and how and where do i install it ?
A lot of this is Greek to me too, but what little i can get from it is a liitle that i did not know before.

The download and instructions are  at http://www.efmer.eu/forum_tt/index.php?topic=428.0. Installation is just a matter of taking the 64 bit version of the executable out of the zip file and putting it someplace convenient. If you have BOINC installed where it chooses by default the program should have no difficulty finding what it needs to work with.

The instructions on that linked page say it will reschedule both VLAR and VHAR to CPU unless you uncheck the "Always move VHAR's to CPU" box, I definitely recommend doing so to keep VHARs on GPU. The only VLARs you might have are some older unmarked ones which have been reissued, x32f is better at doing those than stock 6.10 but probably leaving the "Always move VLAR's to CPU" checked is what you'll want.
                                                                                    Joe

[Jason G]

Agreed, anyone who read and remembered the 19th reply in the first thread you mentioned should not have gotten into difficulties. The second thread is in the section of this site closed to all except developers and alpha testers, so TouchuvGrey will not have seen that. In retrospect, your proactive approach suggested there was a very good idea and I hereby declare you not a part of the "we" who screwed up. And of course your warnings on the main project, etc. were very helpful. So much so that I for one didn't realize until quite recently that the smoldering embers were threatening to turn into a full blown fire.

Basically, the difficulty is we developers and many others here have a very technical orientation. What is obvious to us is not necessarily so for our users, and we failed to communicate effectively across that gap. Even a clear statement on the front page and in the description of the 0.36 downloads that V12 isn't Fermi compatible would not have completely prevented the developing problem, many are buying Fermi cards as an upgrade and no reinstall seems necessary in such cases. I'd be more comfortable if we had at least tried that kind of warning, though.
                                                                                      Joe

It's been a difficult situation.  I for one didn't realise the potential these cards have fully until I installed one, despite being optimistic from the white papers etc.  Only recent directX 11 performance analyses & reviews of these brand new mainstream cards hints that uptake is likely to be huge.   One thing to keep in mind through all this, while looking back, is that not all the knowledge to put the pieces together was publicly available knowledge, and we've yet to see the full changes  to the stock codebase.  That's marketing controls by nVidia, and continues to mean we have to chase our own tails to work stuff out.  It's always unclear with new hardware whether problems lie with the application build, tools & SDK or drivers, or even the hardware.  With the Cuda 3.1 documentation unreleased at the time, there was nothing to suggest the existing applications shouldn't work, except that they didn't, and the stock modifications yet to be seen, along with x32f, contain fixes in Cuda 3.0 code that were not in that documentation, and only vaguely described in Cuda 3.1

I doubt that any additional written warnings would have been effective, over Richard's advice & instructions, & the installer having been marked, as it was, [Don't use this for Fermi] soon after the problem was understood.  I had to bail up several 'honorary testers' over the past couple of months & feed them working applications to minimise fallout & clarify the situation even for myself, and there remain deadfalls for other developers still they may not know about.

Well I promised plenty of Growing Pains 

[Frizz]

... many are buying Fermi cards as an upgrade and no reinstall seems necessary in such cases. ...

How about some kind of GPU detection like in Folding@Home - so the client runs only supported hardware. Plus a force flag that the user has to set explicitly (e.g. in app_info.xml) to make it run anyway. Like that "-forcegpu ati_r700" people had to set until recently to make their ATI HD5xxx cards work.

Since you already print out stuff like "Device 1: GeForce GTX 460, 1023 MiB, regsPerBlock 32768" I guess you already have some sort of GPU detection code in place 

To late now ... but maybe prevent the same thing from happening when Fermi2.0 comes around.

[Jason G]

Since you already print out stuff like "Device 1: GeForce GTX 460, 1023 MiB, regsPerBlock 32768" I guess you already have some kind of GPU detection code in place 

  That one runs on all the nVidia GPUs  and yes, when the internal dispatch mechanisms in the app, runtime and driver use the right kernels for the right device, as nVidia intended, appropriate codepaths from multiple are chosen & executed.  Unfortunately that mechanism didn't exist prior to Cuda 3.0, so older (Pre Cuda 3.0)builds need to be deprecated. 

nVidia builds 'supposedly' now contain 'forward compatible' PTX code, so Fermi 2 'shouldn't' be a problem.  That however requires a crystal ball I don't have to verify, and wouldn't feel comfortable making a build deliberately error out on something it may have worked fine on.

[Fredericx51]

Thanks Joe and Jason for your clear explanation, about CUDA-FERMI (460). Since I'll expect my 470 any
day now, it would be nice to use the right application.

And will it be possible to use a 9800GTX+ and a GTX470, driven by a QX9650, a bit above 'stock' and
low memory latency.(5-5-5-14--1T) @ ~400MHz (FSB=1340MHz; FSB:DRAM=5:6)
O.S. is WIN XP64, BOINC 6.10.58.
Or is this combi making a good test-case, in FERMI testing, already have a SETI Bêta account and have crunched a few hundred AP tasks with rev.434, also rev.422; 393; 280 , on an Q6600+HD5770+4850, host. (WIN XP x86 Pro.; BOINC 6.10.56, all using optimized app's.)

I follow the forum conversation closely, but need some guide to pick the 'right app', for a 470 GPU.