Posts by Sharon

Yes. Do you remember the two different variants for the different driver versions? When upgrading from 8.12 to 9.12 you have to use the other variant. The exit code is just saying that the app can't load the correct dll (that is what changed between the driver versions).

You have to use this version (32bit SSE2, for Catalyst 9.2 and up).

ati_0.20b_win32_SSE2.zip

Compute error
Exit status	-1073741515 (0xffffffffc0000135)
Computer ID	21507
Report deadline	11 Jan 2010 23:12:57 UTC
Run time	0
CPU time	0
stderr out	

<core_client_version>6.10.18</core_client_version>
<![CDATA[
<message>
 - exit code -1073741515 (0xc0000135)
</message>
]]>

Validate state	Invalid

But works on 260 gpu's that don't crunch gpugid anymore, happy!

I can't explain the technicalities of the kernel frequency any better than the readme.txt file. What it does is affects how many chunks the work unit iterations are broken up into. For example on my HD 4890 with the default kernel frequency of 30 Hz the iterations of current tasks are split into 5 chunks and with the kernel frequency set to 20 Hz, split into 4 chunks. You can see this information in your Task details stderr out section, for example: "dividing each iteration in 4 parts | borders of the domains at 0 400 800 1200 1600"

In theory less chunks should be faster to process but I have found with my HD 4890 when I had the wait state at default that it made no noticeable difference if I set f to 20 Hz, 15 Hz or 10 Hz. However when I increased the wait state to 1.1, I chose to set the kernel frequency to 20 Hz because with wait state at 1.1, kernel frequency changes make more difference for me.

My experience with the HD 4890 regarding kernel frequency settings is different than I noticed with my HD 3850. So although the principle is the same the results on different speed GPUs of experimenting with these parameters may be different. This is because the faster the GPU, the less chunks the iterations need to be split into and vice versa. The results of changing the f parameter can also be different for different task sizes. The tasks are all the same size currently but in the past there were short, long and medium length tasks and changing the f parameter from default sometimes made certain length tasks speed up and other length tasks slow down. So GPU core speed, wait state, kernel frequency and task size are all related in a complex way that sometimes means changes in different combinations of w and f parameters do not always result in the expected change in performance.

What I mean by all this, is that although you are free to try parameter settings that work for others, it is not a bad idea to try out a few different combinations yourself to see if they suit your own particular GPU and needs. Some require task processing speed above all else and do not use the computer for anything other than BOINC, some require stability, some require a more responsive desktop and some prefer to run at a reduced GPU utilisation percentage which reduces processing speed but decreases the heat load on their GPU core.

The application was well designed to run with stability and efficiency for the majority of users, so if you are happy with how it performs in an unaltered default configuration, there is no need to be concerned about changing any of these values. If you are comfortable tinkering with things that's fine too, enjoy experimenting. Retaining stability and getting the scheduling right so that BOINC debt does not build up is a more important priority in my opinion than chasing the last few seconds of speed improvement. It's little use flying through the WUs in record time if your GPU locks up every day or if MilkyWay or another project's tasks stop processing for hours at a time because of BOINC scheduling issues.

Nice work -- by the way, do you (or anyone else here) know what the power consumption numbers comparison would be between say the 4830 and a 9800GT?

One thing I've noticed is that the 9800GT cards use a modest amount of power (though a decent 450W or 500W PS seems to work well enough with them) and quite a lot of heat.

Isn't there a way to go into one of the boinc files to change the LTD? It seems to me I read that in a thread a long time ago at SETI.

Yes, go to the Client state file, open with Notepad, search for 'long', change and save.

This must be done with the Boinc client closed imho.

Or see link in my sig... the older non Web version has a "clear" option.

Isn't there a way to go into one of the boinc files to change the LTD? It seems to me I read that in a thread a long time ago at SETI.

Yes, go to the Client state file, open with Notepad, search for 'long', change and save.

This must be done with the Boinc client closed imho.

It would be fine to have 5-10 wu's at a time when the time is extended by say 5-10 times. They would run 55-100 min on mine then.

Minimum needs to me 8. 8-way boxes are just too common any more.

i figured i'd sticky this post because it's something that comes up pretty often.

the reason we can't have more than 20 WUs at a time (and even this is too many) has been discussed on here many times. it's even in the known issues section. what we're doing is dynamically updating a genetic search based on the results you guys return. if we feed out more than 20 workunits (even this is too many) by the time you finish crunching them, the population has moved so far away from where those points were generated that the work you've done on them is basically useless. ideally i'd really like to have the number somewhere around 5-10.

when we update the server code, you should be able to download new workunits as soon as you finish with your previous ones. if you're just complaining about wanting more WUs out there in the case when the server crashes... i don't think theres anything we can do about that as the workunits need to be dynamically generated as new ones come in.

that being said, we definitely are trying to increase the time per workunit. the model will be updated, and we'll be doing it across multiple streams of stars - you just need to be patient with us here. this is science in progress and Nate is working on how exactly to do that. also, i'm working on incorporating doing a line search into a workunit (which should increase the computation time by a factor of 10-50) or more) -- but that's maybe a week or two away because that'll take a bit of bug fixing. i'm hoping to have that in the next version of the application.