While I'm having a bit of a gripe about BRP7 validation rates, there's a point that has been bothering me ever since Bernd made a comment quite some time ago that part of the problem for BRP7 validation variability was due to "noisy data" from time to time, if I remember correctly. In other words, if the signal to noise ratio is low, it's likely that different OSes, compute libraries, drivers, whatever, may end up with different 'toplists' and hence lead to validation inconsistencies where some will win and others will lose.
In those cases, who is to say that the 'closer agreeing' pair of results were the best to choose as the 'canonical' result and saved? Why should the result deemed 'not quite close enough' get no credit at all for the work done?
It would be very nice if the validation process were smart enough to recognise when that type of situation had arisen and instead of outright rejecting the 'not quite close enough' result, still award credit for the work done but ignore it for the purposes of selecting the canonical result. No change to the final outcome as far as the database is concerned but at least some credit for the unlucky machine that got excluded, through no fault of its own.
With the understanding that this is all volunteer work, it WOULD be nice to get a little something in return for "burning" all these electrons to power our computers, regardless of outcome.
That's interesting Gary. I guess we could now have two reasons for validation :
- as a veto (or not) for the purpose of the data analysis pipeline.
- as a 'proof of work' for the granting of credits to the relevant volunteers.
The first is obvious, the second less so. I can't imagine why anyone would want to closely, but not quite, fake any returns to the server. But then again there were those issues with 'optimised' BOINC clients many years ago now (circa 2006).
Cheers, Mike.
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal
I have to note that I'm still seeing a few invalid Bu workunits ever since the BuB's were disabled, which again, I almost never had a invalid Bu workunit before BuB rolled out.
I have to wonder if this is due to my machine going from "GW-opencl-nvidia-2" to "GW-cuda-3", which from my limited searching began after the initial BuB rollout.
I have to note that I'm still seeing a few invalid Bu workunits ever since the BuB's were disabled, which again, I almost never had a invalid Bu workunit before BuB rolled out.
I have to wonder if this is due to my machine going from "GW-opencl-nvidia-2" to "GW-cuda-3", which from my limited searching began after the initial BuB rollout.
it's not due to GW-cuda-3.
the application from cuda-3 and cuda-2 are the exact same binary, simply renamed and no code changes. the only difference is config files packaged with the app. '-2' contained the config files for the HF tasks, and '-3' contains the config files for the BuB tasks.
but the Bu task doesnt use the config files at all, so it doesnt matter what config files are packaged.
I have to note that I'm still seeing a few invalid Bu workunits ever since the BuB's were disabled, which again, I almost never had a invalid Bu workunit before BuB rolled out.
I have to wonder if this is due to my machine going from "GW-opencl-nvidia-2" to "GW-cuda-3", which from my limited searching began after the initial BuB rollout.
it's not due to GW-cuda-3.
the application from cuda-3 and cuda-2 are the exact same binary, simply renamed and no code changes. the only difference is config files packaged with the app. '-2' contained the config files for the HF tasks, and '-3' contains the config files for the BuB tasks.
but the Bu task doesnt use the config files at all, so it doesnt matter what config files are packaged.
Hmm. Hopefully then my invalid rate will slow down and go back to normal as time passes :(
This couldn't be because my system was running OpenCL before and now it's doing CUDA?
Hmm. Hopefully then my invalid rate will slow down and go back to normal as time passes :(
This couldn't be because my system was running OpenCL before and now it's doing CUDA?
looking at your old vs new tasks from your 1080Ti host.
yes you used to be running the OpenCL 1.07 version of the app. this app has CPU recalc computation. (DemodSSE)
but there are actually two versions of the CUDA app on Linux. v1.16 and v1.17 (beta)
v1.16 (analogous to the old 1.14 CUDA app from '-2'). this app uses GPU recalc computation (DemodGPU). personally i notice more Invalids with this application.
and v1.17 (analogous to the old 1.15 CUDA app from '-2'). this app uses CPU recalc computation (DemodSSE) much like the the old 1.07 opencl app does. the only difference between 1.07 and 1.17 is that with v1.17 the GPU search portion uses CUDA instead of OpenCL. historically with the previous batch of tasks this app never really produced any invalids. this app is classified as "beta" from the project, so to get it you need to enable the sending of test applications in your project preferences.
and v1.17 (analogous to the old 1.15 CUDA app from '-2'). this app uses CPU recalc computation (DemodSSE) much like the the old 1.07 opencl app does. the only difference between 1.07 and 1.17 is that with v1.17 the GPU search portion uses CUDA instead of OpenCL. historically with the previous batch of tasks this app never really produced any invalids. this app is classified as "beta" from the project, so to get it you need to enable the sending of test applications in your project preferences.
I see. I've gone ahead and turned on the test applications. Hope this fixes it, thank you!
Gary Roberts wrote: While
)
With the understanding that this is all volunteer work, it WOULD be nice to get a little something in return for "burning" all these electrons to power our computers, regardless of outcome.
Phil
I thought I was wrong once, but I was mistaken.
That's interesting Gary. I
)
That's interesting Gary. I guess we could now have two reasons for validation :
- as a veto (or not) for the purpose of the data analysis pipeline.
- as a 'proof of work' for the granting of credits to the relevant volunteers.
The first is obvious, the second less so. I can't imagine why anyone would want to closely, but not quite, fake any returns to the server. But then again there were those issues with 'optimised' BOINC clients many years ago now (circa 2006).
Cheers, Mike.
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal
I have to note that I'm still
)
I have to note that I'm still seeing a few invalid Bu workunits ever since the BuB's were disabled, which again, I almost never had a invalid Bu workunit before BuB rolled out.
I have to wonder if this is due to my machine going from "GW-opencl-nvidia-2" to "GW-cuda-3", which from my limited searching began after the initial BuB rollout.
Sabrina Tarson wrote:I have
)
it's not due to GW-cuda-3.
the application from cuda-3 and cuda-2 are the exact same binary, simply renamed and no code changes. the only difference is config files packaged with the app. '-2' contained the config files for the HF tasks, and '-3' contains the config files for the BuB tasks.
but the Bu task doesnt use the config files at all, so it doesnt matter what config files are packaged.
_________________________________________________________________________
Ian&Steve C. wrote:Sabrina
)
Hmm. Hopefully then my invalid rate will slow down and go back to normal as time passes :(
This couldn't be because my system was running OpenCL before and now it's doing CUDA?
Sabrina Tarson wrote:Hmm.
)
looking at your old vs new tasks from your 1080Ti host.
yes you used to be running the OpenCL 1.07 version of the app. this app has CPU recalc computation. (DemodSSE)
but there are actually two versions of the CUDA app on Linux. v1.16 and v1.17 (beta)
v1.16 (analogous to the old 1.14 CUDA app from '-2'). this app uses GPU recalc computation (DemodGPU). personally i notice more Invalids with this application.
and v1.17 (analogous to the old 1.15 CUDA app from '-2'). this app uses CPU recalc computation (DemodSSE) much like the the old 1.07 opencl app does. the only difference between 1.07 and 1.17 is that with v1.17 the GPU search portion uses CUDA instead of OpenCL. historically with the previous batch of tasks this app never really produced any invalids. this app is classified as "beta" from the project, so to get it you need to enable the sending of test applications in your project preferences.
_________________________________________________________________________
Ian&Steve C. wrote: and v1.17
)
I see. I've gone ahead and turned on the test applications. Hope this fixes it, thank you!