Second WU completed & validated against a CUDA device. Good job!
Processing third WU - no square dots on screen.
Memory usage back to 369MB(dedicated), ~38MB(dynamic).
Looks like there may be a problem with initial run.
Scenario 1: Reboot > BOINC > run WU.
Square dots on screen, no driver restart.
Consecutive WU ran fine, with no square dots on screen, no driver restart.
Scenario 2: Reboot > runs some apps > BOINC > run WU.
Will report back tomorrow.
What we are beginning to see as a trend is that HD 6900 series cards have a far harder time to produce cross-validating results than both older and younger cards (meaning they seem to produce less accurate results with the current app).
The difference is not dramatic but I wonder whether the HD 6900 owners are experiencing this in other projects as well?
Wow. I find that very strange as the 69xx series cards are double precision vs. the single precision of the NVIDIA and single precision AMD (54xx-57xx, 63xx-68xx, 73xx-76xx) cards.
At Milkyway double precision cards are required. I haven't had any validation errors with my 6950.
The Einstein@Hom app does not need (and does not use) any double precision arithmetic on the GPU, so this should not be a factor.
At the moment the higher validation failure rate for 6900 series cards is just an observation of correlation, no claim of causality :-), as the number of cards on the Albert@Home project is just too small. It could be an indirect effect, e.g. the FFT lib could choose to switch to a different, but less accurate, code path on 6900 cards because of differences in the runtime characteristics. We'll look into it. Any experience wrt this from other projects is welcome.
The Einstein@Home app does not need (and does not use) any double precision arithmetic on the GPU, so this should not be a factor.
I am aware. The point I was trying to make, though, was that how the math is coded matters greatly and does impact precision of the final answer. Let's take for example pi^16 (exaggerated for show) with 3 different approximations for pi.
I did these in excel with the last set of calculations using the actual pi() function in excel (which obviously shows decimal truncations).
So, **in general**, the more precision you start with, the better your final answer (depending on a host of other things I forget from my numerical computation class), but you pay for it with computation time. But I'm sure I'm not telling you guys anything new.
Just out of curiosity, was the Einstein app ever run in double precision and compared to results of single precision calculations? I presume it was based on "does not need", but I'd be interested to know the difference.
Quote:
At the moment the higher validation failure rate for 6900 series cards is just an observation of correlation, no claim of causality :-), as the number of cards on the Albert@Home project is just too small. It could be an indirect effect, e.g. the FFT lib could choose to switch to a different, but less accurate, code path on 6900 cards because of differences in the runtime characteristics. We'll look into it. Any experience wrt this from other projects is welcome.
All my above hot air aside, I could have sworn I remember reading somewhere about the accuracy of OpenCL results and a statement to the effect of "it seems AMD has ditched some precision in lieu of speed", however I thought that was rectified with new catalyst drivers. Maybe send a PM to Raistmer on the Seti@Home Beta boards. I'm more than positive he will know (I think he's the one who originally posted it).
The apps are the same as used here, but note that the minimum BOINC client version was again increased to 7.0.27 (the most recent development version atm).
We will continue to improve the app so that we will again need beta testers at Albert@Home in the near future, but just now you will probably want to scale back the work at Albert a bit and throw your ATI-cards on the Einstein@Home production project.
The apps are the same as used here, but note that the minimum BOINC client version was again increased to 7.0.27 (the most recent development version atm).
We will continue to improve the app so that we will again need beta testers at Albert@Home in the near future, but just now you will probably want to scale back the work at Albert a bit and throw your ATI-cards on the Einstein@Home production project.
Thanks again,
HB
That sounds great. You will cancel the unsent WUs?
Then we could just keep our machines polling the servers and will get new work and apps as soon as you have them.
I see one result that IS valid, so it's not like strictly all results are junk.
Out of curiorisity I would underclock the card and see what happens.
Sometimes hardware just fails, e.g. I have one fairly old NVIDIA GT 9800 that tends to produce long runs of invalid results, and then again returns to normal. I have a strong suspicion that for that particular card this correlates strongly with (room) temperature. I consider it semi-broken by now and shut it down during summer. So there can be a grey zone between good and broken.
v1.24 The app still corrupts
)
v1.24
The app still corrupts the screen with square dots during the initial start-up.
But there is not driver restart.
Memory usage is 369MB(dedicated), ~39MB(dynamic).
Seems faster.
Will be running consecutive WUs this round using this host.
1st result reported.
2nd WU ran fine without any square dots on screen.
Memory usage is higher.
475MB(dedicated), ~38MB(dynamic).
-- terencewee* Sicituradastra.
First WU awaiting
)
First WU awaiting validation.
Second WU completed & validated against a CUDA device. Good job!
Processing third WU - no square dots on screen.
Memory usage back to 369MB(dedicated), ~38MB(dynamic).
Looks like there may be a problem with initial run.
Scenario 1: Reboot > BOINC > run WU.
Square dots on screen, no driver restart.
Consecutive WU ran fine, with no square dots on screen, no driver restart.
Scenario 2: Reboot > runs some apps > BOINC > run WU.
Will report back tomorrow.
-- terencewee* Sicituradastra.
Hi all! What we are
)
Hi all!
What we are beginning to see as a trend is that HD 6900 series cards have a far harder time to produce cross-validating results than both older and younger cards (meaning they seem to produce less accurate results with the current app).
The difference is not dramatic but I wonder whether the HD 6900 owners are experiencing this in other projects as well?
Cheers
HB
Wow. I find that very strange
)
Wow. I find that very strange as the 69xx series cards are double precision vs. the single precision of the NVIDIA and single precision AMD (54xx-57xx, 63xx-68xx, 73xx-76xx) cards.
At Milkyway double precision cards are required. I haven't had any validation errors with my 6950.
http://en.wikipedia.org/wiki/Comparison_of_AMD_graphics_processing_units
The Einstein@Hom app does not
)
The Einstein@Hom app does not need (and does not use) any double precision arithmetic on the GPU, so this should not be a factor.
At the moment the higher validation failure rate for 6900 series cards is just an observation of correlation, no claim of causality :-), as the number of cards on the Albert@Home project is just too small. It could be an indirect effect, e.g. the FFT lib could choose to switch to a different, but less accurate, code path on 6900 cards because of differences in the runtime characteristics. We'll look into it. Any experience wrt this from other projects is welcome.
Cheers
HB
RE: The Einstein@Home app
)
I am aware. The point I was trying to make, though, was that how the math is coded matters greatly and does impact precision of the final answer. Let's take for example pi^16 (exaggerated for show) with 3 different approximations for pi.
I did these in excel with the last set of calculations using the actual pi() function in excel (which obviously shows decimal truncations).
So, **in general**, the more precision you start with, the better your final answer (depending on a host of other things I forget from my numerical computation class), but you pay for it with computation time. But I'm sure I'm not telling you guys anything new.
Just out of curiosity, was the Einstein app ever run in double precision and compared to results of single precision calculations? I presume it was based on "does not need", but I'd be interested to know the difference.
All my above hot air aside, I could have sworn I remember reading somewhere about the accuracy of OpenCL results and a statement to the effect of "it seems AMD has ditched some precision in lieu of speed", however I thought that was rectified with new catalyst drivers. Maybe send a PM to Raistmer on the Seti@Home Beta boards. I'm more than positive he will know (I think he's the one who originally posted it).
Hi all! With the help of
)
Hi all!
With the help of your continued support, we were able to put the ATI/OpenCL app into production on Einstein@Home today.
[url]http://einstein.phys.uwm.edu/forum_thread.php?id=9446[\url]
The apps are the same as used here, but note that the minimum BOINC client version was again increased to 7.0.27 (the most recent development version atm).
We will continue to improve the app so that we will again need beta testers at Albert@Home in the near future, but just now you will probably want to scale back the work at Albert a bit and throw your ATI-cards on the Einstein@Home production project.
Thanks again,
HB
RE: Hi all! With the help
)
That sounds great. You will cancel the unsent WUs?
Then we could just keep our machines polling the servers and will get new work and apps as soon as you have them.
Christoph
My 7970 is producing nothing
)
My 7970 is producing nothing but validation errors:
http://albertathome.org/host/2209/tasks&offset=0&show_names=0&state=4&appid=
Any ideas why?
Dublin, California
Team: SETI.USA
Hmmm... GPU temperature is
)
Hmmm... GPU temperature is ok??
I see one result that IS valid, so it's not like strictly all results are junk.
Out of curiorisity I would underclock the card and see what happens.
Sometimes hardware just fails, e.g. I have one fairly old NVIDIA GT 9800 that tends to produce long runs of invalid results, and then again returns to normal. I have a strong suspicion that for that particular card this correlates strongly with (room) temperature. I consider it semi-broken by now and shut it down during summer. So there can be a grey zone between good and broken.
Cheers
HB