Other than that, your result just doesn't match those of the other two closely enough for the tolerances defined in our validator - I'm not sure how that came about, but this occasionally happens to all of us.
We recently had a discussion on the validation rates for, specifically, the Binary Radio Pulsar Search (Arecibo) (BRP4) app on Intel iGPUs, and I posted some figures in comment 183546. My older, slower, iGPUs had a validation failure rate of some 3-4%, but my newest and fastest iGPU had a rate around 10%.
Since then, I've updated all my video drivers to the newest available direct from Intel, to test some complete failures at another project. Since then, my task completion times on all cards have fallen, but my validation failure rates have increased.
We have a suspicion that an OpenCL compiler optimisation flag generates faster, but less precise, binary kernels: I've heard a 'Fused Multiply-Add' opcode suggested as a culprit.
FGRPB1G is out of work to send. systems failed over to GW.
and again.
So you set on the website profile to send other work if no gamma ray is available?
I have not had much luck with that trick on e@h. So I run pure gr on my highest performing box.
Tom M
A Proud member of the O.F.A. (Old Farts Association). Be well, do good work, and keep in touch.® (Garrison Keillor) I want some more patience. RIGHT NOW!
it worked when GR was run out. but when GR work returned, it didnt stop processing GW and flip back to GR like it's supposed to. it just kept crunching away on GW.
FGRPB1G is out of work to send. systems failed over to GW.
and again.
and again.
seems like something is going on with the GR process or server. it's struggling to keep up the past few days. maybe the admins need to have it generate more work to have on standby, or initiate work generation sooner than when the available tasks hits zero to preempt it running dry.
FGRPB1G is out of work to send. systems failed over to GW.
and again.
and again.
seems like something is going on with the GR process or server. it's struggling to keep up the past few days. maybe the admins need to have it generate more work to have on standby, or initiate work generation sooner than when the available tasks hits zero to preempt it running dry.
FGRPB1G is out of work to send. systems failed over to GW.
and again.
and again.
seems like something is going on with the GR process or server. it's struggling to keep up the past few days. maybe the admins need to have it generate more work to have on standby, or initiate work generation sooner than when the available tasks hits zero to preempt it running dry.
FGRPB1G is out of work to send. systems failed over to GW.
and again.
and again.
seems like something is going on with the GR process or server. it's struggling to keep up the past few days. maybe the admins need to have it generate more work to have on standby, or initiate work generation sooner than when the available tasks hits zero to preempt it running dry.
Once upon a time one of the differences in speed between the Nvidia GPUs and the Radeon GPUs was what happened at 89%.
The Radon GPUs would pause and then "snap" to 100%.
The Nvidia GPUs would keep munching and then (eventually) get to 100%
Lately, it seems like the Radeons are pausing a couple of minutes at 89% and then jumping to 100%.
Both of my Nvidia GPUs are offline at the moment.
Are the Nvidias munching steadily or are they pausing at 89% and jumping to 100% after a couple of minutes?
Thank you.
Tom M
A Proud member of the O.F.A. (Old Farts Association). Be well, do good work, and keep in touch.® (Garrison Keillor) I want some more patience. RIGHT NOW!
Bernd Machenschalk
)
We recently had a discussion on the validation rates for, specifically, the Binary Radio Pulsar Search (Arecibo) (BRP4) app on Intel iGPUs, and I posted some figures in comment 183546. My older, slower, iGPUs had a validation failure rate of some 3-4%, but my newest and fastest iGPU had a rate around 10%.
Since then, I've updated all my video drivers to the newest available direct from Intel, to test some complete failures at another project. Since then, my task completion times on all cards have fallen, but my validation failure rates have increased.
We have a suspicion that an OpenCL compiler optimisation flag generates faster, but less precise, binary kernels: I've heard a 'Fused Multiply-Add' opcode suggested as a culprit.
Could this be investigated, perhaps?
FGRPB1G is out of work to
)
FGRPB1G is out of work to send. systems failed over to GW.
_________________________________________________________________________
Ian&Steve C. wrote: FGRPB1G
)
and again.
_________________________________________________________________________
Ian&Steve C.
)
So you set on the website profile to send other work if no gamma ray is available?
I have not had much luck with that trick on e@h. So I run pure gr on my highest performing box.
Tom M
A Proud member of the O.F.A. (Old Farts Association). Be well, do good work, and keep in touch.® (Garrison Keillor) I want some more patience. RIGHT NOW!
it worked when GR was run
)
it worked when GR was run out. but when GR work returned, it didnt stop processing GW and flip back to GR like it's supposed to. it just kept crunching away on GW.
so I just disabled that setting again.
_________________________________________________________________________
Ian&Steve C.
)
and again.
seems like something is going on with the GR process or server. it's struggling to keep up the past few days. maybe the admins need to have it generate more work to have on standby, or initiate work generation sooner than when the available tasks hits zero to preempt it running dry.
_________________________________________________________________________
Ian&Steve C.
)
and again
_________________________________________________________________________
Ian&Steve C.
)
and again.
_________________________________________________________________________
Ian&Steve C.
)
and again
_________________________________________________________________________
Once upon a time one of the
)
Once upon a time one of the differences in speed between the Nvidia GPUs and the Radeon GPUs was what happened at 89%.
The Radon GPUs would pause and then "snap" to 100%.
The Nvidia GPUs would keep munching and then (eventually) get to 100%
Lately, it seems like the Radeons are pausing a couple of minutes at 89% and then jumping to 100%.
Both of my Nvidia GPUs are offline at the moment.
Are the Nvidias munching steadily or are they pausing at 89% and jumping to 100% after a couple of minutes?
Thank you.
Tom M
A Proud member of the O.F.A. (Old Farts Association). Be well, do good work, and keep in touch.® (Garrison Keillor) I want some more patience. RIGHT NOW!