Message boards :
News :
testing new validator
Message board moderation
Previous · 1 · 2 · 3 · 4 · 5 · 6 · 7 · Next
Author | Message |
---|---|
Send message Joined: 22 Nov 07 Posts: 285 Credit: 1,076,786,368 RAC: 0 |
Ditto, I stopped using the opti apps (except for the CPU) several weeks ago.. I am getting hundreds of invalids.. none of my cards are overclocked everything stock. So, how do you intend to correct this? If 1 or 2 hosts in the quorum are using stock apps but are returning invalid results, could there be something wrong with the stock app and not the validation? . |
Send message Joined: 22 Nov 07 Posts: 285 Credit: 1,076,786,368 RAC: 0 |
On another note, does anyone know if the 48xx or the 58xx ATI GPU is the one validating correctly vs the stock application? Here is as host that I have switched from Stock to opti back to stock.. both apps see to be having problems. 5870 - single card, no overclock. http://milkyway.cs.rpi.edu/milkyway/show_host_detail.php?hostid=47682 . |
Send message Joined: 30 Aug 07 Posts: 2046 Credit: 26,480 RAC: 0 |
On another note, does anyone know if the 48xx or the 58xx ATI GPU is the one validating correctly vs the stock application? What I'm trying to figure out is if say a stock application result and 2 48xx GPU results come back, do they validate to a quorum? (that would mean the issue is with the 58xx GPU application). Otherwise, if a stock application result and 2 58xx GPU results make a quorum, that would mean the 48xx GPU application is the problem. |
Send message Joined: 11 Nov 07 Posts: 232 Credit: 178,229,009 RAC: 0 |
Seams to be a lot of wasted computer power. Why do you keep on sending out new wu's? |
Send message Joined: 30 Aug 07 Posts: 2046 Credit: 26,480 RAC: 0 |
Seams to be a lot of wasted computer power. It won't be as bad once we get the GPU issue sorted out and the hosts error rates updated in the database. We'll be moving to a quorum of 2 and ~10% validation for results that don't improve our searches (unless that host is known to be a repeat offender when it comes to errors); which will really be minimal duplicate work. Right now I'm just trying to flush out bad clients that are running single precision GPU applications or scripts. |
Send message Joined: 30 Dec 07 Posts: 311 Credit: 149,490,184 RAC: 0 |
What I'm trying to figure out is if say a stock application result and 2 48xx GPU results come back, do they validate to a quorum? (that would mean the issue is with the 58xx GPU application). Not all GPUs are the same brand or architecture class but neither are all CPUs. So what is considered a stock application result, an unoptimised CPU application running on a certain model Intel CPU or an unoptimised CPU application running on a certain model AMD CPU? Or does the CPU architecture make no difference to the result? I am just trying to make sure that the term "stock application result" is understood in the same way by all reading or contributing to the thread. Many believe that the ATI GPU application automatically sent by the server is the "stock" application and the one that is manually downloaded and installed by contributors is the "optimised" application, but they are often both the same application. In this sense all GPU applications are "optimised" and only the original CPU application automatically downloaded could be considered the stock application. If unoptimised application CPU results are in between the results of 48xx and 58xx, then is it possible that they would not validate with either GPU class or with both? Hopefully we will find out soon, if there was a test application available I still couldn't work it out myself unless I also had a test validator. |
Send message Joined: 30 Aug 07 Posts: 2046 Credit: 26,480 RAC: 0 |
What I'm trying to figure out is if say a stock application result and 2 48xx GPU results come back, do they validate to a quorum? (that would mean the issue is with the 58xx GPU application). As far as I know, all the applications we provide (the stock applications) provide results with 10e-13 of each other, regardless of them being on a CPU or GPU. |
Send message Joined: 12 Nov 07 Posts: 2425 Credit: 524,164 RAC: 0 |
As far as I know, all the applications we provide (the stock applications) provide results with 10e-13 of each other, regardless of them being on a CPU or GPU. Awhile back you said you only needed to the 8th place and would like to get to the 10th. That is what I thought all of these applications were based off of. Doesn't expecting the unexpected make the unexpected the expected? If it makes sense, DON'T do it. |
Send message Joined: 30 Aug 07 Posts: 2046 Credit: 26,480 RAC: 0 |
As far as I know, all the applications we provide (the stock applications) provide results with 10e-13 of each other, regardless of them being on a CPU or GPU. As far as I remember, we've always wanted 10+ degrees of precision. If we were content with 8 we could be using single precision applications. |
Send message Joined: 14 Dec 09 Posts: 161 Credit: 589,318,064 RAC: 0 |
Double precision is accurate to the 12th decimal. What about these "completed, validation inconclusive" ones? Are they waiting for the other quorums to be validated? |
Send message Joined: 30 Dec 07 Posts: 311 Credit: 149,490,184 RAC: 0 |
As far as I know, all the applications we provide (the stock applications) provide results with 10e-13 of each other, regardless of them being on a CPU or GPU. Thanks for the clarification of what stock means. I thought the GPU applications were compared to a CPU for accuracy when they were developed not compared to other GPU results. |
Send message Joined: 12 Nov 07 Posts: 2425 Credit: 524,164 RAC: 0 |
As far as I know, all the applications we provide (the stock applications) provide results with 10e-13 of each other, regardless of them being on a CPU or GPU. Could have been talking about single precision apps. Doesn't expecting the unexpected make the unexpected the expected? If it makes sense, DON'T do it. |
Send message Joined: 30 Dec 07 Posts: 311 Credit: 149,490,184 RAC: 0 |
Two comparisons which include unoptimised CPU application in the quorum. wuid=90266299 -3.16876629868666400000 48xx Anonymous v0.20b Invalid -3.16876629868695500000 CPU Core2 Duo E6750 v0.19 Invalid -3.16876639500725200000 58xx Anonymous v0.22 Valid -3.16876639500725200000 58xx Anonymous v0.22 Valid -3.16876639500713000000 58xx Anonymous v0.20b Valid wuid=90249810 -3.17153809050878900000 48xx v0.21 (ati13ati) Valid -3.17153809050878900000 48xx v0.21 (ati13ati) Valid -3.17153818333960200000 58xx Anonymous v0.22 Invalid -3.17153809050889600000 CPU Core2 Duo E6750 v0.19 Valid 48xx results agree with stock CPU application results to 12 decimal places but 58xx results only agree with stock CPU application results to 6 decimal places. I do not know if results from an unoptimised stock CPU application are considered to have the highest degree of accuracy, so I will not draw any conclusions, except to repeat my original belief that the differences seen are hardware based and not application based. It appears that Cypress based ATI cards give different results to other hardware classes. |
Send message Joined: 22 Mar 09 Posts: 99 Credit: 503,422,495 RAC: 0 |
I´m wondering about the "new" observation that different architectures lead to different results even with the same application. I´m crunching CPDN for about five years and hardly have seen two identical or nearly identical results even with the same application (because the applications are closed). Maybe the goal of accuracy is to challenging. In my ten years of DC I remember a project (but I don´t know which) that sent WUs only to hosts with the same CPU knowing that AMD and Intel produces different results. Of course remember the pentium bug on the first pentiums ;-) |
Send message Joined: 26 Jul 08 Posts: 627 Credit: 94,940,203 RAC: 0 |
I've posted some results including the optimized CPU and CUDA application in the other thread. Only the HD5800 series GPUs deviate substantially. All others are well within the bounds set by the project. There is something fishy going on for sure. Bad thing is I have no idea what. I guess the best would be if the HD5800 users take a short break or support another project until we figure out what is going on here. |
Send message Joined: 30 Aug 07 Posts: 2046 Credit: 26,480 RAC: 0 |
I've posted some results including the optimized CPU and CUDA application in the other thread. Only the HD5800 series GPUs deviate substantially. All others are well within the bounds set by the project. Yeah I've modified the validator on my end to get more information about what's going on, and the 5800s are the ones giving off results (by about ~9e-8). 4800s validate vs. stock and CUDA just fine. |
Send message Joined: 26 Jul 08 Posts: 627 Credit: 94,940,203 RAC: 0 |
I´m wondering about the "new" observation that different architectures lead to different results even with the same application. I´m crunching CPDN for about five years and hardly have seen two identical or nearly identical results even with the same application (because the applications are closed). Maybe the goal of accuracy is to challenging. As shown in the other thread HD3800/4700/4800 GPUs return the exact same fitness value as CPUs with my versions. So at least here it is possible. I've told Anthony and Travis already some time ago, that I think the CUDA version could probably return the same values too. The behaviour of the HD58x0 GPUs is definitely peculiar and probably some kind of mess-up on some thing that simply needs to be found and fixed. |
Send message Joined: 9 Apr 09 Posts: 10 Credit: 117,669,581 RAC: 0 |
Ok, well I just set all my 5850s to NNW. I have been using the optimized .20b application.... Let us know when it is safe to return :) |
Send message Joined: 22 Mar 09 Posts: 99 Credit: 503,422,495 RAC: 0 |
HD3800/4700/4800 GPUs return the exact same fitness value as CPUs with my versions. So at least here it is possible. I've told Anthony and Travis already some time ago, that I think the CUDA version could probably return the same values too. I´m only CPU-cruncher on MW, but my accurate results were errored out because that four 58x0 overruled my result as could be seen here: http://milkyway.cs.rpi.edu/milkyway/workunit.php?wuid=90277453 Will I get my credits back? I have a valid result with 4800, my CPU and a cuda-app and the 5800 was marked as invalid. (http://milkyway.cs.rpi.edu/milkyway/workunit.php?wuid=90148812) This supports the statement of Cluster Physik. |
Send message Joined: 14 Feb 09 Posts: 999 Credit: 74,932,619 RAC: 0 |
Is it possible for you to compile a test case for those of us who have both 48xx and 58xx cards so we can run them and see what is really doing the good work. At Lunatics we have a bench suite that allows us to test new builds of the Astropulse apps. |
©2024 Astroinformatics Group