We have submitted a new batch of TRYP (*adTRYP*), significantly longer than the latest TRYP (met*, eth*, pro*,...).

The latest TRYP were a real production attempt to straighforwardly obtain binding for small inhibitor molecules. It finally proved harder than first expected, therefore we are improving the underlying analysis method as well as implementing a cleverer scheme to obtain the data. That is what *adTRYP* are for, to prepare a systematic methodological study on how to produce efficiently many events of binding for small protein inhibitors. See experiments section for more info.

I have one of these *adTRYP* running on my GTX480@800MHz. It's computation reached 10% in 55 minutes and 40 seconds. It's running with 75% GPU usage (Swan_sync=0 applied, WindowsXP 32bit). So it will finish on my GTX480@800MHz in approximately 9 hours and 17 minutes.

Yes, Ignasi's adTRYP tasks are Long; I'm expecting one to finish in ~13.5h (3h 38 @ 28%) on a mildly overclocked GTX470 (680MHz), 1 CPU thread free, but not using SWAN_SYNC. Getting ~66% GPU utilization (2003 R2 x64 server). I guess SWAN_SYNC would do more for these tasks, as might freeing an additional thread. These are not for entry level cards!

I turned SWAN_SYNC on, restarted and freed up 3 CPU threads (really just 2 as SWAN eats one up). Utilization rose to ~72%. Total run time should now be around 12.5h.
When I freed up all the CPU threads the GPU utilization rose to 79%.
72/66 is about 9% faster and 79/66 is around 19% faster, so the system can be tweaked to improve GPU performance, if you so desire.
An OC'ed CPU with HT switched off might improve GPU performance further, but you have to find your own balance in these situations. I'm happy to free 2 or 3 cores but not to switch off HT, OC the CPU, or free up all the CPU cores. If I had a couple of GTX 580's in the system, I expect all of the above would be implemented.
____________FAQ's

It then took approximately another 10 hours for the WU to successfully upload. It only successfully uploaded after I returned home from work, and sat and pressed the retry button for about a half-hour.

This is why I find the 24-hour limit on first tier bonus credits distasteful as I feel this penalizes people in my situation, and people in my situation have no control over problems with uploading results. I've done everything in my power to correct this without success as evidenced by this thread - http://www.gpugrid.net/forum_thread.php?id=2713

178-IBUCH_adTRYP_120402-0-5-RND1445_5
Worked quite OK on my machine, after having previously failed on 4 others machines.
And it only took about 9.6 hours to run to completion.
Do you think that my (unusually huge) amount of GPU RAM (3Gb on *each* GTX580) might be the clue here?
Or could it be the 12 cores, or the 24Gb of CPU RAM?
Dunno.
But no "large" task has failed to run to completion for some months now, if ever.
I must be getting *something* right that differs from others'?

Contrast this system. An all too common bad setup; CC1.1 card, running long tasks, keeping a high cache, failing most tasks, using an alpha Boinc client, also using W7 and one of the unrecommended drivers.

Might I suggest then, that operations might be enhanced by encouraging participants who have buggy-drivers, (No, not those with horse-and-cart!), to adopt a more friendly version?
As you know who they are, as well as their contact details, surely it would not be too onerous to create a script that 'points' each user to the appropriate download page?
And advising those with inappropriate task-selection/Graphics-card combinations to change? Or changing their selections of task types automatically, even?

All good positive suggestions, but all down to the researchers to move forward/implement, or not.
I'm just a forum mod and tester, I don't have access to emails and I can't alter users settings. I did suggest that moderators be allowed to alter settings under certain circumstances, such as continuous failures or being asked to by the cruncher. However, even if we could do these things we could not install drivers. We can't select task types here, so when we get failures on one task type, they just keep coming! I think a server side system to prevent this should be considered. We don't loose a lot of credit when a task fails in the first few seconds, but long tasks in particular do eat up lots of 'premium' bandwidth.
____________FAQ's