Forum > GPU crunching
GTX 460 superclocked
Miep:
So, in essence, people don't read or if they read they don't pay enough attention to details. They skip over the paragraphs, only taking in what they want and screw everything up.
Same in discussions, people never listen properly. But there at least you can yell at them.
[Doesn't strike me as a particularly new insight. Even people who should know better sometimes miss things.]
From the slightly outside POV, there was plenty of information there - at least on NC. A whole thread dedicated on how to get a nice app_info to run Fermis for example.
So the problem remains, not to put information out there, but to get it across.
I think once 0.37 is out, I'll have to start yelling at people...
@Fredericx I'm sure Jason will be delighted to hear whether or not x32f_30 runs errorfree on that mixture.
TouchuvGrey:
--- Quote from: Josef W. Segur on 25 Aug 2010, 12:23:08 am ---
--- Quote from: perryjay on 24 Aug 2010, 07:28:21 pm ---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.
--- Quote --- i plead guilty as charged, i have a long history of not reading the instructions.
--- End quote ---
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. ;D
--- End quote ---
--- Quote from: TouchuvGrey on 24 Aug 2010, 07:44:57 pm --- 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.
--- End quote ---
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
--- End quote ---
"Always move VHAR's to CPU" unchecked, "limit rsc_fpops...." checked. Is there anything
else i should change from default ?
Miep:
--- Quote from: TouchuvGrey on 25 Aug 2010, 07:14:08 am ---"Always move VHAR's to CPU" unchecked, "limit rsc_fpops...." checked. Is there anything
else i should change from default ?
--- End quote ---
I think Fred has previously recommended running in Simulation mode once and check the log for errors, before running for real.
Making a backup of the Boinc Data folder before major operiations is also usually a good idea.
perryjay:
I also checked "do not include running tasks in reschedule" as I believe someone had a little problem with that messing up the running tasks but I'm going by memory there and it's not always the best. ::) I'm just going by "better safe than sorry" on that one.
Richard Haselgrove:
--- Quote from: Josef W. Segur on 24 Aug 2010, 06:06:41 pm ---
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
--- End quote ---
--- Quote from: Richard Haselgrove on 24 Aug 2010, 07:00:49 pm ---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
--- End quote ---
--- Quote from: Josef W. Segur on 24 Aug 2010, 11:58:14 pm ---
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
--- End quote ---
Sorry about the mixed thread references, but it was just a quick way of reminding both audiences who will be reading this thread - the technical audience who make the applications work, and the consumer audience who enjoy the fruits of their labours - how we came to be in this situation.
Let's be clear, the problem of Fermi compatibility - and in particular, the problem that older builds, including NVidia's own as supplied for Berkeley to use as stock apps - wouldn't run on Fermi cards only became apparent well after Fermi cards (GTX 4xx series) started to sell and be installed in significant numbers. And it was mainly those early purchasers who got caught by it. And understanding of the nature of the issues involved was substantially delayed by the conflicting signals about app_info errors coming from the faulty BOINC scheduler deployed around that time.
But if there can be one problem like this, there can also be more in the future. And that raises two questions. What do the ordinary, downloading and using, consumers of Lunatics applications expect? And what do the developers and other volunteers feel able to supply?
For a long time, Lunatics' optimised applications were prominently flagged as "FOR ADVANCED USERS ONLY". That meant that if anybody wanted to take advantage of the speed and efficiency of optimised applications, they absolutely had to put some time and effort into learning, at least in general terms, how BOINC's application controls work. More recently, Lunatics - or in particular, Jason on Lunatics' behalf - has responded to user feedback by making the process of installing the applications easier and more user-friendly. That has reduced the amount of effort and knowledge required of end users, at the expense of significantly increasing the complexity and size of the workload that Jason is shouldering on behalf of you all (as a volunteer, with other work commitments competing for time as well).
That second thread I linked was a suggestion for an updated installer to work round the Fermi problem, without requiring any additional manual updating from users themselves. Jason's reply started "I'm under time pressure with 'other things'", and after discussion, the decision was taken to leave the known-problematic applications in the installer, but supplement them with warnings and links to guidance on the additional steps required. Maybe, with hindsight, that's the point at which good intentions started to diverge from best practice and the expectations of users.
It does make me wonder, given the limited amount of volunteer time available, and the limited number of people available to supply it, whether the time might have come to separate the roles of application development and optimisation (Lunatics' historic primary focus), from the more mundane tasks of package management and deployment. Speaking from personal experience of being a sole developer/deployer, the multiplicity of tools and techniques involved can slow down ones ability to use any one of them effectively when competing time constraints arise.
Now that the basic framework of the installer process has been tried and tested, would there be any scope for a specialist volunteer to take over package maintenance, and release Jason to concentrate on the real hard work of coding and optimisation? One problem is that it would have to be somebody who already has, or could be entrusted with, the security authority to fiddle with the contents of the download area - quality control there is paramount. Any merit in that approach, and more importantly, any suitably qualified volunteers? (I possibly come fairly close, but I couldn't think of putting myself forward until after the BOINC workshop and a holiday planned for next month).
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version