I figured that the event log is just an indication of a problem but not much help in finding the reason. However, I still don't know exactly what data I can provide that might shed some light on this. For all I know perhaps Grid staff already have the diagnostic data they need/want from my BOINC client.

If uplinger or other staff reach out and ask for specific data I'd be happy to provide it if I can. Alternatively, if my GPU turns out to be too old and is to be unsupported it would be best if these units weren't offered for such cards. Although I didn't mention it earlier, this is a Windows client.

There was talk about your card either in this thread or in the one dated 3/12/21. Searching them may help sort out your issue. IIRC other people had issues with the 730.

Two topics that I've been resisting saying much on as there is already a lot of comment, but I think they are worth saying:

First, when running multiple copies on an NVidia GPU, it makes far more sense to me to set gpu_usage=0.5 (or whatever accordingly to how many copies), but always set cpu_usage=1. Why? Because with opencl on NVidia the CPU busy-waits for the GPU for each copy of the task. So you should always have a complete CPU allocated for each copy. I always override the just-below-one values sent by some apps. Without that you can easily end up over-allocating your CPUs if you are also running some CPU tasks. I'm only saying this about NVidia opencl though - I don't think it applies to Nvidia CUDA (which OPN isn't), and I don't know what the situation is on AMD/Intel. And the optimal settings may be different when the full-sized tasks arrive.

Secondly, the dreaded points. My rationale:
1. Don't use CPU time. It will be distorted for Nvidia (see above). It incentivises running things inefficiently (e.g. over-allocating CPUs) which achieves less work.
2. Don't use GPU time. It doesn't reflect work done. It also incentivises over-committing your GPU so extend GPU times at the expense of reducing work done. But even worse it incentivises using the slowest lowest-power-consumption GPU you can, resulting in much less useful work.
3. Don't use elapsed time. Similar arguments to above.
4. Do use Gflops if you can readily obtain them. It reflects useful work done. I don't really see why the same sort of per-Gflop value shouldn't apply as for CPU.
5. If you don't have Gflops available, just use a fixed value per task. Overs and unders will even out.
6. Don't use zero. I don't care about points but many do. I do care about having their GPUs working on perhaps the most important project ever. If you have to give points to get them to do that then give points. It's not going to cost any real money.
7. Give enough points to remain competitive with other GPU projects. Same rationale as previous point.

And a final thought.... I applaud WCG working on all 9 platform combinations. But I'd really like to see each of those 9 platforms moved into production as soon as it is ready, rather than waiting until all 9 are. I believe it is an urgent enough project to warrant that.

Thanks

Good afternoon,

I am not going to be adding any new work on to the beta test right now or the rest of this weekend. I have plenty of results and I have quickly read through a lot of the comments and suggestions from everyone. I will take more time on Monday morning going through and examining what we have.

There are a few things I may want to try....One of which would be a target for fixing the GT cards on NVIDIA...The other is, I want to atleast put in place a point system for the next round of beta...ya'll deserve credit and time that your systems are computing work units.

At the moment, depending on what the researchers say, this might be our first GA release...the numbers on everything look very promising and well within reason for acceptable error/invalid rates. I personally have an aggressive timeline I wish to get this to production, but I know we will atleast have one more beta tests which will be to remove the dlg files from being sent back and to confirm backend processes work correctly with that.

Thanks,
-Uplinger

I don't know what core client your using that writes it's own xml files but I would not use it under any circumstances. I know of no BOINC code that was written specifically for BT so I'll have to take you word for that. More than likely the horribly written code is your problem so why use it? I don't understand why someone is trying to reinvent the wheel. Stand alone BOINC with the BT app has worked fine for a long time. My suggestion would be to install the most up to date version of BOINC from the Berkley site, write your own xml files as needed and dump whatever it is you're trying to make work here. Good luck.