Good evening everyone. I apologize for being MIA the past few days. Here are some of the developments that have been going on.

1. I got a new Mac build machine that I was working towards getting up and configured properly. However, I have time boxed that and ran out of that time :P So for now the next version of the application, 7.28 will be built using the old build machine.
2. We did get the code changes and they required a manual review of it from myself and another developer on WCG to make sure that everything was in good shape. This passed our examines with an A-. It did have an issue with windows and using std::min and std::max...but we corrected those in the version sent to you.
3. I started an Alpha test earlier today and have seen results coming back from those machines and things are looking proper. very good chance that we will see a beta tomorrow morning (my time, Texas ya'll [ say that with a good texan accent in your head] )
4. I am increasing the max elapsed time from the 20x to 100x as the differences between the top of the line GPU and the some of the intel gpus differ greatly.
5. The next beta will still include the dlg file that needs to be uploaded as these results will go back to the researchers to make sure that the rehydration of the results is what they expect.
6. I have been going over the scheduler and checking to see about fixing the credits per result that are given. I still do not have that fixed, however, I will not keep points from launching this to production if a solution is not available. I understand points are important to some, but having GPU running sooner than later is best in my opinion.

Thanks,
-Uplinger

I seem to have a pretty good trend of end of the week beta tests...not exactly the pattern I was going for, but a pattern none the less.

Unfortunately for the credit on the first GPU it didn't have knowledge of previous points, so it was skewed to grant the max points allowed...which didn't seem wrong at the time...but it going to 0 is pretty much exactly the wrong thing I want to happen. I have toyed with the idea of granting points based on how many ligands are processed per work unit. However since it's not apples to apples with the CPU version, that seems incorrect. But not ruled out entirely.

As for the estimated size, I did use the average size reported by all results, however, the last beta had older cards able to operate because of the single precision fix. This caused the difference between the fastest and the slowest to diverge even greater. I have it on my release plan for tomorrow to have those updated for the new results sent out.

Thanks again for the feedback and all the help in the forums.

-Uplinger

I don't quite understand your point here. The 'size' of a task (rsc_fpops_est) should be a dimensionless number - the number of floating point operations needed to compute the result required. Apart from a single experiment at SETI@Home, over 10 years ago, no BOINC science application that I know of has ever counted or reported the number of flops performed.

What BOINC can do, and does, is report time. Not unnaturally, the fastest devices report the shortest time. Taking an average of time, over these limited test runs, is open to distortion - the fastest cards will also complete a greater number of tasks before they run out, and exaggerate the number of short times in the sample.

Artificially boosting the rsc_fpops_bound will be helpful in getting a fuller picture of the results returned, but should not be necessary for regular running. Because the time limit is calculated pro-rata for each host, based on the known size of the task and speed of the device, there should be no need to adjust the bound once a realistic value for rsc_fpops_est is established.

The other situation where the time estimate can be exceeded is when an application stalls and no further mathematical progress is being made. In the case, the placebo effect of BOINC's reported pseudo-progress can direct the attention in the wrong direction. Extending the bound in this case will merely waste more electricity before the task is eventually aborted.

I am new to this particular project, and I don't yet have a full understanding of the procedure for assessing points or credits here. I'll refrain from commenting on those until I know more.

Hi:
Well, the GeForce GTX 660M VC in my Alienware laptop bombed out again.
Anybody else experienced a similar failure?
Clive Hunt

Hi:
I have a GTX660M VC in my laptop as well. I am curious what VC did you replace it with.
Cehunt