zero credits for valid result??
Message boards : Number crunching : zero credits for valid result??
Author | Message | |
---|---|---|
This
workunit
shows some errors and therefor I got no credits? And there is still a result not yet returned.
|
||
ID: 301 | Rating: 0 | rate: / | ||
I'm not getting what would you like to change? A higher number for max errors?
|
||
ID: 302 | Rating: 0 | rate: / | ||
I'm not getting what would you like to change? A higher number for max errors? Either a higher number for max errors or, even better, do not send out more results of a workunit if max errors is already reached ;-) I don't want to look for each WU I get if the max errors is reached and then abort this WU before it gets crunched. |
||
ID: 303 | Rating: 0 | rate: / | ||
It's Alpha, we asked for it ;)
|
||
ID: 304 | Rating: 0 | rate: / | ||
Errors belong nevertheless here on this fora, as the team ahs to know about them to learn from them. That's what alphas is about: Make errors, try to find out what happened, and eliminate the cause. That is the major cause I began this thread: to give a hint that somewhere is something wrong. |
||
ID: 306 | Rating: 0 | rate: / | ||
I'm not sure there's a problem yet for the WU in question.
|
||
ID: 307 | Rating: 0 | rate: / | ||
If you were right why is the granted credits 0.00? It should show 'pending' and when the next result returns valid, then the appropiate credits should be granted.
|
||
ID: 309 | Rating: 0 | rate: / | ||
The status of that WU has now changed to "too many error results", and BOINC has decided the WU is bad, and awards no credit. |
||
ID: 310 | Rating: 0 | rate: / | ||
The status of that WU has now changed to "too many error results", and BOINC has decided the WU is bad, and awards no credit. That status was already there when I started this thread, thus the problem is still the same. |
||
ID: 313 | Rating: 0 | rate: / | ||
Saenger is correct and we appreciate any errors :-) Solving them is in another league, but we do our best!
[quote]Errors belong nevertheless here on this fora, as the team ahs to know about them to learn from them. That's what alphas is about: Make errors, try to find out what happened, and eliminate the cause. |
||
ID: 315 | Rating: 0 | rate: / | ||
We might do the same if we find out how... If anybody can offer any help as to how to do this it will be appreciated. We are not boinc-ignorants, but also not complete experts on the system yet :-)
Albeit, some projects during alpha stage gives credit to machines that completed valid results regardless if WU as validated as a whole.) |
||
ID: 316 | Rating: 0 | rate: / | ||
We might do the same if we find out how... If anybody can offer any help as to how to do this it will be appreciated. We are not boinc-ignorants, but also not complete experts on the system yet :-)I believe Bernhard of RCN used semi-automatic script for that; better ask him. |
||
ID: 325 | Rating: 0 | rate: / | ||
Simple enough. BOINC generated three results (9250, 9251, 9252). At first you see the first three errored out, but thing is they weren't returned within the same minute.
|
||
ID: 335 | Rating: 0 | rate: / | ||
I tried out a Docking WU on an old box to see how it would take it. It took over 16 hours, but I had no problems with it. For some reason it didn't validate though, even though it reported "success" (as above).
|
||
ID: 430 | Rating: 0 | rate: / | ||
|
||
ID: 433 | Rating: 0 | rate: / | ||
Hi Bruce,
____________ D@H the greatest project in the world... a while from now! |
||
ID: 435 | Rating: 0 | rate: / | ||
I think it has something to do with the fact that I've increased the min_quorum parameter from 2 to 3 again which is the value we will use when we will move from alpha to the next phase. I'm not completely sure yet though because these results have already been deleted from the system. I'd like to give you credit for it, but I don't know how yet.
I tried out a Docking WU on an old box to see how it would take it. It took over 16 hours, but I had no problems with it. For some reason it didn't validate though, even though it reported "success" (as above). ____________ D@H the greatest project in the world... a while from now! |
||
ID: 436 | Rating: 0 | rate: / | ||
Honza,
We might do the same if we find out how... If anybody can offer any help as to how to do this it will be appreciated. We are not boinc-ignorants, but also not complete experts on the system yet :-)I believe Bernhard of RCN used semi-automatic script for that; better ask him. ____________ D@H the greatest project in the world... a while from now! |
||
ID: 437 | Rating: 0 | rate: / | ||
Hi Bruce, they have been unhid. :) |
||
ID: 442 | Rating: 0 | rate: / | ||
Hi Bruce, they have been unhid. :) |
||
ID: 443 | Rating: 0 | rate: / | ||
Honza, Done. |
||
ID: 448 | Rating: 0 | rate: / | ||
Honza, Got it! ____________ D@H the greatest project in the world... a while from now! |
||
ID: 456 | Rating: 0 | rate: / | ||
While checking a couple of your results, it is what I expected: your results where actually correct but compared to invalid results that successfully validated because of the bug in 5.1. This should not happen anymore with 5.2. Until everybody is crunching 5.2 WUs this might still happen sporadically though.
Hi Bruce, ____________ D@H the greatest project in the world... a while from now! |
||
ID: 457 | Rating: 0 | rate: / | ||
While checking a couple of your results, it is what I expected: your results where actually correct but compared to invalid results that successfully validated because of the bug in 5.1. This should not happen anymore with 5.2. Until everybody is crunching 5.2 WUs this might still happen sporadically though. Thank you for the quick reply Andre! :) |
||
ID: 474 | Rating: 0 | rate: / | ||
Bruce,
While checking a couple of your results, it is what I expected: your results where actually correct but compared to invalid results that successfully validated because of the bug in 5.1. This should not happen anymore with 5.2. Until everybody is crunching 5.2 WUs this might still happen sporadically though. ____________ D@H the greatest project in the world... a while from now! |
||
ID: 475 | Rating: 0 | rate: / | ||
I am still seeing this problem in both 5.02 and 5.03, even when all hosts in the quorum are running the same app. It appears to be happening on older systems like
this one
of mine. Granted, I have not run D@H on it since that first problematic result (it took about 16 hours for that host to crunch the WU and I wanted to make sure the issue was fixed before I ran another one), but I have been keeping an eye on
one of my teammate's hosts
that is marginally faster but very similar, and he has continued to get the same validation problem for successful results.
|
||
ID: 604 | Rating: 0 | rate: / | ||
Same problem here on my older system:
here.
|
||
ID: 605 | Rating: 0 | rate: / | ||
Same problem here on my older system: here. Yeah Shrub, that's the one I was looking at. I had been watching that host of yours, to see how its results were treated before I reattached my old one. I looked at some other users setups to see if they were having the same problem, but couldn't find anyone else running geriatric systems to compare ours to. ____________ KWSN - Asylum for the Cynically Insane |
||
ID: 606 | Rating: 0 | rate: / | ||
Actually it appears to be a validation issue. That host is still running Boinc 5.4.9 (although I'm sure many others are as well) but I'd be inclined to believe it's a computation difference between CPU architecture.
|
||
ID: 607 | Rating: 0 | rate: / | ||
Actually I am looking into this problem. I have an old PIII 667 running linux and it went from all invalid to some invalid. I don't think it's the ammount of credit requested as I have seen that for the same WU a 3 GHz claimed more... I will bring this up at the weekly meeting in the mean time any ideas are welcome. Thanks for all the support and CPU time that you all have given to the project. |
||
ID: 609 | Rating: 0 | rate: / | ||
Actually I am looking into this problem. I have an old PIII 667 running linux and it went from all invalid to some invalid. I don't think it's the ammount of credit requested as I have seen that for the same WU a 3 GHz claimed more... I will bring this up at the weekly meeting in the mean time any ideas are welcome. Thanks for all the support and CPU time that you all have given to the project. Not sure if BOINC will even give you the tools to address this problem. From what I've picked up on various other message boards it won't let you assign work based on processor speed. I'm pretty certain that would be the fix if it could be implemented. Every PIII I've run across in the results table here (running Windows at least) is exhibiting the same problem. On my system I ran it over two versions of BOINC and both the 5.02 and 5.03 Docking applications. Every result is still marked invalid and zero credits. As always let me know if you need further results and I'll run a batch through. ____________ KWSN - A Shrubbery http://www.kwsnforum.com |
||
ID: 734 | Rating: 0 | rate: / | ||
This workunit shows some errors and therefor I got no credits? And there is still a result not yet returned. Yes, but in that situation two crunchers had some credits, at least! Look at this, it happened to me... 0 credits because of an errored WU among many valid results. what a mess! This is not unfair, this is absurd :) |
||
ID: 1254 | Rating: 0 | rate: / | ||
I have to find out what boinc is doing with this workunit, but I have the feeling it has to do with the max. number of results been reached. It shouldn't assign 0 credits to all valid results though. Thanks for letting us know, we are learning every day :-)
This workunit shows some errors and therefor I got no credits? And there is still a result not yet returned. ____________ D@H the greatest project in the world... a while from now! |
||
ID: 1288 | Rating: 0 | rate: / | ||
I have to find out what boinc is doing with this workunit, but I have the feeling it has to do with the max. number of results been reached. It shouldn't assign 0 credits to all valid results though. Thanks for letting us know, we are learning every day :-) My pleasure, this is the way I can help here :-) [edit]I just noticed that this workunit for some reason got an initial replication of 7. The system should initially create 3 replicas and distribute these to hosts. Because the max. nr of successful results is set to 5 and 6 results came back valid, boinc decided to grant no credits at all. I will see if I can correct this somehow. Good and fast work in guessing the error. Also if that WU can't be "fixed", there will be many many others. Have a good day |
||
ID: 1304 | Rating: 0 | rate: / | ||
Haha, I had something similar too :) Increased initial replication to 10 to test something, max total results was 9! It was marked as invalid as soon as one result was back. |
||
ID: 1307 | Rating: 0 | rate: / | ||
Reporting a invalid / error result by even just linking will help developers to work on that:) ____________ I'm a volunteer participant; my views are not necessarily those of Docking@Home or its participating institutions. |
||
ID: 1308 | Rating: 0 | rate: / | ||
No, it was my fault, I set the replication higher than the limit, that would obviously cause it to reach the limit even before it starts :\ |
||
ID: 1309 | Rating: 0 | rate: / | ||
Ah, I got it:) |
||
ID: 1310 | Rating: 0 | rate: / | ||
Hmmm, I didn't do any testing though... We have a test server specifically for testing :-) Maybe a gremlin in the boinc system :-)
____________ D@H the greatest project in the world... a while from now! |
||
ID: 1311 | Rating: 0 | rate: / | ||
not sure why no credit was granted on these:
|
||
ID: 1340 | Rating: 0 | rate: / | ||
not sure why no credit was granted on these: Validator said they were invalid, either by checking or by comparing with other results. |
||
ID: 1341 | Rating: 0 | rate: / | ||
"SUCCESS - Charmm exited with code 0." looks valid to me regardless what the validator says. there are other results with the exact same message that were marked as valid. |
||
ID: 1342 | Rating: 0 | rate: / | ||
"SUCCESS - Charmm exited with code 0." looks valid to me regardless what the validator says. there are other results with the exact same message that were marked as valid. That message says nothing, you have to compare the actual output file, not just the messages. It could also be a validator problem. |
||
ID: 1343 | Rating: 0 | rate: / | ||
"SUCCESS - Charmm exited with code 0." looks valid to me regardless what the validator says. there are other results with the exact same message that were marked as valid. A validator's problem :) Or maybe a wrong indication given to the validator by the admins. |
||
ID: 1349 | Rating: 0 | rate: / | ||
> No credit on http://docking.utep.edu/results.php?resultid=40729
|
||
ID: 1351 | Rating: 0 | rate: / | ||
First of all, yes, something went wrong with this WU. I checked the md5 checksums of the results returned by the computers and they look indeed to be right. On the other hand, success or code 0 by charmm only means that charmm (the app that does all the crunching) finished all the tasks assigned with no errors. Validated is one two or more computers (depending on the HR being used) returned identical results.
|
||
ID: 1377 | Rating: 0 | rate: / | ||
I think I have seen two or three WUs with the same problem. As what was the problem I don't know. I will ask Andre since he is the one working with the HR in boinc at the moment. I will be able to tell him in about a week since he is at SC this coming week. But he has wireless access to the machines from SC though :-) When I find some time, I can try to check it out... Andre ____________ D@H the greatest project in the world... a while from now! |
||
ID: 1390 | Rating: 0 | rate: / | ||
This
WorkUnit
looks valid but gave me 0 and says Invalid... while the others had credits :-(
|
||
ID: 1446 | Rating: 0 | rate: / | ||
This WorkUnit looks valid but gave me 0 and says Invalid... while the others had credits :-( Actually the results that you sent are different to the other two results. We compare the results and give credit to results that are identical. I see its your first work unit... lets wait for some more and see if your computer's behavior keeps repeating. |
||
ID: 1447 | Rating: 0 | rate: / | ||
ok... i've another one pending... let's hope this one will be ok |
||
ID: 1451 | Rating: 0 | rate: / | ||
Your CPU is from the PIII era. Not likely to be granted any credits until the validator issue has been resolved. It's being worked on currently.
|
||
ID: 1453 | Rating: 0 | rate: / | ||
This WorkUnit looks valid but gave me 0 and says Invalid... while the others had credits :-( Looks to me like "Ye Olde P3 problem" . For some reason, the results from Pentium III's do not play nice with others. The developers are aware of this problem, and are still working on a fix. Last I heard, they were discussing designating certain WUs for P3's, separating them from other CPU types so that they would only be matched with other P3's results, much the same way that systems running Linux, Mac, and Windows are grouped separately. EDIT: Blast it Shrub, you beat me to it! |
||
ID: 1455 | Rating: 0 | rate: / | ||
Your CPU is from the PIII era. Not likely to be granted any credits until the validator issue has been resolved. It's being worked on currently. mmmh... that makes me ask a maybe stupid question: A different answer to the same WU doesn't mean a wrong answer? In this case the problem is not in the validator but in the cruncher application... |
||
ID: 1456 | Rating: 0 | rate: / | ||
Your CPU is from the PIII era. Not likely to be granted any credits until the validator issue has been resolved. It's being worked on currently. It's not actually a problem with the validator, that is working as intended. The problem is that even though the result is probably right, it is different therefore invalid. ____________ KWSN - A Shrubbery http://www.kwsnforum.com |
||
ID: 1459 | Rating: 0 | rate: / | ||
> No credit on http://docking.utep.edu/results.php?resultid=40729 Wondering if there has been an answer about this yet? Still have no credit for this WU. Also if you have 2 results that are equal do you really need the third? See following results as they also returned Zero credits for the 2 succeful returned results but also had 4 compute/abort errors http://docking.utep.edu/results.php?resultid=46317 http://docking.utep.edu/results.php?resultid=46168 Thanks. ____________ |
||
ID: 1473 | Rating: 0 | rate: / | ||
Have a w/u here, that was successful, yet was not granted credit. This is not a P.C. problem, turned in a w/u the same session, with granted credit.
|
||
ID: 1478 | Rating: 0 | rate: / | ||
This seems to be a strange quirk in the boinc validator code. The number of target results gets bumped up if the number of success results is larger than the number of target results:
} else { // here if no consensus. // check if #success results is too large // if (nsuccess_results > wu.max_success_results) { wu.error_mask |= WU_ERROR_TOO_MANY_SUCCESS_RESULTS; transition_time = IMMEDIATE; } // if #success results == than target_nresults, // we need more results, so bump target_nresults // NOTE: nsuccess_results should never be > target_nresults, // but accommodate that if it should happen // if (nsuccess_results >= wu.target_nresults) { wu.target_nresults = nsuccess_results+1; transition_time = IMMEDIATE; } At some point this will go past the max. number of successful results and all results get invalidated (see code above). I will try to find out more about this, because it doesn't make complete sense to me. By the way, this only happened in 37 cases in the database, so not too much. But still want to find out why the validator does this. Andre > No credit on http://docking.utep.edu/results.php?resultid=40729 ____________ D@H the greatest project in the world... a while from now! |
||
ID: 1479 | Rating: 0 | rate: / | ||
Doug,
Have a w/u here, that was successful, yet was not granted credit. This is not a P.C. problem, turned in a w/u the same session, with granted credit. ____________ D@H the greatest project in the world... a while from now! |
||
ID: 1480 | Rating: 0 | rate: / | ||
This seems to be a strange quirk in the boinc validator code. The number of target results gets bumped up if the number of success results is larger than the number of target results: Hint: boinc_projects mailing list :) |
||
ID: 1483 | Rating: 0 | rate: / | ||
Is there any hint in the mailing list?
|
||
ID: 1492 | Rating: 0 | rate: / | ||
|
||
ID: 1496 | Rating: 0 | rate: / | ||
Unless I go into the database and manually change the credits in there, no BOINC won't give you any credits for this result because the calculated result was wrong. And to be honest, I don't think we should do that unless we do this for all the other people/results in the db that experienced this, and to be honest that would take some time to put a script or something together, which can be better spent on the app problem. I hope you understand....
____________ D@H the greatest project in the world... a while from now! |
||
ID: 1501 | Rating: 0 | rate: / | ||
Unless I go into the database and manually change the credits in there, no BOINC won't give you any credits for this result because the calculated result was wrong. And to be honest, I don't think we should do that unless we do this for all the other people/results in the db that experienced this, and to be honest that would take some time to put a script or something together, which can be better spent on the app problem. I hope you understand.... Thanks Andre, Understand perectly.Good luck with the new app, happy to understand also, that it is not this P.C. that weirded out, but the app. Keep up the good work. DOUG ____________ |
||
ID: 1506 | Rating: 0 | rate: / | ||
Could someone tell me what is wrong with these results ?
|
||
ID: 1692 | Rating: 0 | rate: / | ||
Could someone tell me what is wrong with these results ? The basic problem is that it's a Pentium III CPU which was mixed in with results from Pentium 4 CPU's. Some new instructions were added to the P4 and above, which are not on the P-III. The project is supposed to be grouping the results together based on CPU type (Homogeneous Redundancy) but that obviously failed in this situation so the work units didn't validate, although the client on your machine reported success. These results would probably have gotten credit if they had been mixed with other P-II or P-III results. It might have to do with the original work unit being issued before they figured out that this particular problem existed so something in the server database allowed it to be re-issued to a P-III when that particular work unit shouldn't have been.
These work units (WU) have both the Homogeneous Redundancy (HR) problem and only gave credit to 2 machines when they show as having a minimum quorum of 3 machines. IIRC, 2 used to be the minimum quorum. It looks like the list of machines that should be allowed to process the WU, the minimum quorum, and possibly the max # of success results were set in stone in the server database when the work unit was originally issued. You didn't get credit because of the HR problem, but it looks like there are other problems with granting credit on the server side. They're good about trying to straighten these things out, but you might never get credit for these WU because they would spend all their time granting people credit in the database instead of fixing the problems that caused them not to get credit in the first place. I think they have fixed the HR problem, so once the old WU are out of the system, you should start getting credit for your work. I'm just another volunteer tester like yourself, not someone with the project, so take my answers with a grain of salt until you can get an official answer. I'm sorry you had these problems, but they are just learning to use the server side of the BOINC software themselves and it's a system which appears to have some subtleties that are taking them a while to find and figure out solutions for. Getting the project client to work on so many different CPU's and versions of operating systems has caused them a lot of grief since the CPU, BIOS, and multiple Operating systems (versions, patch levels, and distributions of the OS used) can cause subtle differences in floating point processing which cause the results not to match each other. On the server side, they're having to learn the subtleties of some complex software that was written by someone else. On the client side, they're dealing with a really complicated problem with these floating point differences. They have a huge amount of work to do and not many people to do it with, so we're trying to go easy on them about a few credits lost while the project is in Alpha Test mode. Again, I'm sorry you didn't get credit for all your computers work. Many of us have experienced the same thing, especially on Linux and x86 Macs. It's one of the hazards of a pre-beta test project, but we get to work closely with the developers and have a nice little community here so please don't be upset over the lost credits. After all, on production projects, a single volunteer can't have anywhere close to the impact on the future of the project that those of us who are here as it's being developed can have. I hope you won't be discouraged by this. The developers take problems we report very seriously and work to prevent them in the future. Regards, -- David |
||
ID: 1694 | Rating: 1 | rate: / | ||
I have just reattatched one of my P3's (
host 1070
)to the project, and from what I'm seeing already, I am pretty convinced that this issue has not been fixed. Of the 9 WUs that I received, several of them have not been matched up with other hosts yet, and I will keep a watchful (and hopeful) eye on them to see what type of systems those resuts get sent to; however, of the 3 that have so far filled the initial quorum replication, my P3 host has been matched with other non P3 Intel hosts as seen
here
,
here
, and
here
. That last one was an older WU, created a week before the HR changes were announced, but all the rest were created Dec, 2nd and 3rd. I have already aborted those 3 so that new results could be sent out. And now that I check again, I am seeing that even in a WU where my P3 was the first host to recieve work in a quorum, the other replications are still being sent to non P2/P3/AMD systems, as evidenced
here
.
|
||
ID: 1695 | Rating: 0 | rate: / | ||
Could someone tell me what is wrong with these results ? Thanks David, I thought that issue had be resloved. I guess not, i will detach my pIII for now. Thanks again David, it is appreciated. |
||
ID: 1698 | Rating: 0 | rate: / | ||
This is definitely weird... All of our tests on DockTest checked out successful, but on Docking somehow it doesn't work... Hmmm... I will have to do some DB analysis to find out if that is the case for all workunits or only for some (like yours). Thanks for pointing this out Atomic!
I have just reattatched one of my P3's ( host 1070 )to the project, and from what I'm seeing already, I am pretty convinced that this issue has not been fixed. Of the 9 WUs that I received, several of them have not been matched up with other hosts yet, and I will keep a watchful (and hopeful) eye on them to see what type of systems those resuts get sent to; however, of the 3 that have so far filled the initial quorum replication, my P3 host has been matched with other non P3 Intel hosts as seen here , here , and here . That last one was an older WU, created a week before the HR changes were announced, but all the rest were created Dec, 2nd and 3rd. I have already aborted those 3 so that new results could be sent out. And now that I check again, I am seeing that even in a WU where my P3 was the first host to recieve work in a quorum, the other replications are still being sent to non P2/P3/AMD systems, as evidenced here . ____________ D@H the greatest project in the world... a while from now! |
||
ID: 1699 | Rating: 0 | rate: / | ||
The PII and PIII fix for Windows is on the system now. This will hopefully help getting the number of validating results up. Please let us know if you find any anomalies.
|
||
ID: 1714 | Rating: 0 | rate: / | ||
After over a week of waiting for pending results, it seems that the P3 solution for Windows is not did not do the trick.
This workunit here
was sent to my P3 (host 1070) and matched with 2 AMD hosts, just as planned, but my successful result was yet again deemed invalid. I have 5 or 6 results still pending, and I will let you know if any of those validate, however, I'm not very optimistic.
|
||
ID: 1771 | Rating: 0 | rate: / | ||
Yes, unfortunately it does not appear the problem has been resolved.
|
||
ID: 1779 | Rating: 0 | rate: / | ||
Yes, unfortunately it does not appear the problem has been resolved. Hi Richard, Do you know if that P-III is a Coppermine (0.180 micron) or a Tualatin (0.130 micron) version of the cpu? IIRC, the 1.13 GHz Coppermine P-III was recalled as unstable. I don't even know if there was a mobile version of the Coppermine P-III at that speed. I'm not aware of any problems with the Tualatin Version which is what I think you have, but I thought I should mention it. You might want to run a good memory test and some other diagnostics on the machine, just in case. Do you know which chipset your motherboard uses? Regards, -- David |
||
ID: 1783 | Rating: 0 | rate: / | ||
I will do some benchmarks to see what is going on with P3/windows combination. |
||
ID: 1792 | Rating: 0 | rate: / | ||
Thanks Memo! :) |
||
ID: 1808 | Rating: 0 | rate: / | ||
Hello all,
|
||
ID: 1826 | Rating: 0 | rate: / | ||
Hello Alex,
Hello all, ____________ D@H the greatest project in the world... a while from now! |
||
ID: 1827 | Rating: 0 | rate: / | ||
Hello Andre,
|
||
ID: 1842 | Rating: 0 | rate: / | ||
Hi,
|
||
ID: 1882 | Rating: 0 | rate: / | ||
Hi Tim,
Hi, ____________ D@H the greatest project in the world... a while from now! |
||
ID: 1884 | Rating: 0 | rate: / | ||
Hi Andre and Tim,
|
||
ID: 1886 | Rating: 0 | rate: / | ||
Hi Tim, Do you think that it may have something to do with all the writing to disk that may introduce small errors somehow? This seems to be the only project that has so much disk writing. Can you alter it at all? |
||
ID: 1890 | Rating: 0 | rate: / | ||
I did a quickly check last night on my P4HT and I found a WU that was validated against a core 2 due and a Pentium D. We all got credit. I will check some more units. |
||
ID: 1891 | Rating: 0 | rate: / | ||
This is something we have thought of and will be checking after the holidays. The way we checkpoint right now might have something to do with results being different (this just came up in a discussion I had with Michela yesterday). We will change the checkpointing soon to make sure we keep track of a volunteer's disk writing preference; we don't use this at the moment, because of how the checkpointing works.
Do you think that it may have something to do with all the writing to disk that may introduce small errors somehow? This seems to be the only project that has so much disk writing. Can you alter it at all? ____________ D@H the greatest project in the world... a while from now! |
||
ID: 1892 | Rating: 0 | rate: / | ||
I am trying to deliver at least one result with
each of my computers
for the current HR test, including the Pentium III and the AMD K6-III, which have not delivered any valid results so far. Hope that helps.
|
||
ID: 1969 | Rating: 0 | rate: / | ||
I am trying to deliver at least one result with each of my computers for the current HR test, including the Pentium III and the AMD K6-III, which have not delivered any valid results so far. Hope that helps. It does. Thanks! Is there any fixed deadline for the HR test? No fixed deadline. Until we have all of our architectural difference problems solved (and we're getting there slowly, slowly) Andre Regards ____________ D@H the greatest project in the world... a while from now! |
||
ID: 1970 | Rating: 0 | rate: / | ||
January 3, 2007 23:30:00 I have just returned one result for workunit ID 19355 with my Pentium III. This workunit has also been sent to computer ID 745 , which is an "AuthenticAMD x86 Family 6 Model 4 Stepping 2 1333MHz" (maybe an older Athlon-class processor). Could this be an error concerning HR classification? I received this workunit on the 5 Jan 2007 15:11:04 UTC, so I guess this was after the above mentioned reassignment. Regards Alex |
||
ID: 1971 | Rating: 0 | rate: / | ||
Hi Alex,
January 3, 2007 23:30:00 ____________ D@H the greatest project in the world... a while from now! |
||
ID: 1972 | Rating: 0 | rate: / | ||
> Two work units have completed successfully but then it appears that they were both cancelled before anyone else was sent the WUs. Did I miss something or was a batch cancelled? They processed with no errors and I have received no credit.
|
||
ID: 1996 | Rating: 0 | rate: / | ||
Sorry Conan,
> Two work units have completed successfully but then it appears that they were both cancelled before anyone else was sent the WUs. Did I miss something or was a batch cancelled? They processed with no errors and I have received no credit. ____________ D@H the greatest project in the world... a while from now! |
||
ID: 2001 | Rating: 0 | rate: / | ||
In case you notice before we do that that machine finished, please write us a note (like this one) on the forum. Hello Andre, the AMD box has returned its result this morning: workunit ID 19355 However, the third result for this workunit has not been sent to a client up to now. I also noticed that computer 745 is running Windows NT, which might be the reason for the cpu type "AuthenticAMD x86 Family 6 Model 4 Stepping 2 1333MHz" in BOINC instead of the usual "AuthenticAMD AMD Athlon(tm) something". EDIT: There is another workunit, where my Pentium III and this AMD 6.4.2 1333 MHz are sharing a quorum: workunit ID 19592 Same situation, we have both returned, but the third result is unsent right now. You can also see, that all earlier valid results of the AMD in question have been validated against other AMD cpus. Hmm... I guess it really depends now on which type of cpu will get the third result of the quorum. Regards Alex |
||
ID: 2026 | Rating: 0 | rate: / | ||
Just checked my
computers results
- loads of zero credits for valid results, but the workunits for which appear to have been sent out after 1) there was no reply from "Anonymous" and 2) the deadline had passed.
|
||
ID: 2087 | Rating: 0 | rate: / | ||
Hello Martin, welcome to the board:)
Just checked my computers results - loads of zero credits for valid results, but the workunits for which appear to have been sent out after 1) there was no reply from "Anonymous" and 2) the deadline had passed. On this post Andre argued that this seemed due to a BOINC bug. You should check which version of the application had crunched the other tasks, and if they are different from one which your host are using, I think you should abort the tasks and suspend if you mind having other invalid results. suguruhirahara ____________ I'm a volunteer participant; my views are not necessarily those of Docking@Home or its participating institutions. |
||
ID: 2088 | Rating: 0 | rate: / | ||
Hello suguruhirahara.
|
||
ID: 2089 | Rating: 0 | rate: / | ||
Since we do not have such a AMD machine (family 6) in the lab, I'd like to see what result that one will give compared to your pentium III. In case you notice before we do that that machine finished, please write us a note (like this one) on the forum. Hi Andre, please see here for a first result validation of this AMD machine against a Pentium III. |
||
ID: 2144 | Rating: 0 | rate: / | ||
Thanks Alex,
Since we do not have such a AMD machine (family 6) in the lab, I'd like to see what result that one will give compared to your pentium III. In case you notice before we do that that machine finished, please write us a note (like this one) on the forum. ____________ D@H the greatest project in the world... a while from now! |
||
ID: 2148 | Rating: 0 | rate: / | ||
hello
|
||
ID: 2177 | Rating: 0 | rate: / | ||
Hello frank, your result was calculated with charmm 5.04, the other two results of the quorum were calculated with charmm 5.03 before the version switch took place. This should be the reason why your result was invalid. It might have been ok when validated against other 5.04 results. Hopefully, the number of remaining quorums with two 5.03 results and one missing will decrease more and more until all of them are finished. The two fellow crunchers who got their credit with your result are grateful, I guess. But there is something else: in your result is a lot of output from BURP and RenderFarm included. Something got mixed up there. I don't know if this is a real problem or only some leftovers roaming around without doing real harm. Regards Alex My results during the HR tests |
||
ID: 2184 | Rating: 0 | rate: / | ||
hello alexander
|
||
ID: 2191 | Rating: 0 | rate: / | ||
Check out the LHC boards as someone (actually 3 or 4 people i think) there had problems with invalid mixed results from different projects. Its a BOINC issue sadly and nope nothing to do with apps in memory from my memory. i might have a second to look into after work tomorrow but unfortunately if i want to wake up for work tomorrow i really have to sleep now. if you find it please post and i wont go looking, if you don't ill post what i find once i have a chance.
|
||
ID: 2206 | Rating: 0 | rate: / | ||
Message boards : Number crunching : zero credits for valid result??
Database Error: The MySQL server is running with the --read-only option so it cannot execute this statement
array(3) { [0]=> array(7) { ["file"]=> string(47) "/boinc/projects/docking/html_v2/inc/db_conn.inc" ["line"]=> int(97) ["function"]=> string(8) "do_query" ["class"]=> string(6) "DbConn" ["object"]=> object(DbConn)#104 (2) { ["db_conn"]=> resource(198) of type (mysql link persistent) ["db_name"]=> string(7) "docking" } ["type"]=> string(2) "->" ["args"]=> array(1) { [0]=> &string(50) "update DBNAME.thread set views=views+1 where id=41" } } [1]=> array(7) { ["file"]=> string(48) "/boinc/projects/docking/html_v2/inc/forum_db.inc" ["line"]=> int(60) ["function"]=> string(6) "update" ["class"]=> string(6) "DbConn" ["object"]=> object(DbConn)#104 (2) { ["db_conn"]=> resource(198) of type (mysql link persistent) ["db_name"]=> string(7) "docking" } ["type"]=> string(2) "->" ["args"]=> array(3) { [0]=> object(BoincThread)#3 (16) { ["id"]=> string(2) "41" ["forum"]=> string(1) "2" ["owner"]=> string(2) "35" ["status"]=> string(1) "0" ["title"]=> string(31) "zero credits for valid result??" ["timestamp"]=> string(10) "1169103183" ["views"]=> string(4) "3093" ["replies"]=> string(2) "98" ["activity"]=> string(20) "3.9426001447836e-125" ["sufferers"]=> string(1) "0" ["score"]=> string(1) "0" ["votes"]=> string(1) "0" ["create_time"]=> string(10) "1158512484" ["hidden"]=> string(1) "0" ["sticky"]=> string(1) "0" ["locked"]=> string(1) "0" } [1]=> &string(6) "thread" [2]=> &string(13) "views=views+1" } } [2]=> array(7) { ["file"]=> string(63) "/boinc/projects/docking/html_v2/user/community/forum/thread.php" ["line"]=> int(184) ["function"]=> string(6) "update" ["class"]=> string(11) "BoincThread" ["object"]=> object(BoincThread)#3 (16) { ["id"]=> string(2) "41" ["forum"]=> string(1) "2" ["owner"]=> string(2) "35" ["status"]=> string(1) "0" ["title"]=> string(31) "zero credits for valid result??" ["timestamp"]=> string(10) "1169103183" ["views"]=> string(4) "3093" ["replies"]=> string(2) "98" ["activity"]=> string(20) "3.9426001447836e-125" ["sufferers"]=> string(1) "0" ["score"]=> string(1) "0" ["votes"]=> string(1) "0" ["create_time"]=> string(10) "1158512484" ["hidden"]=> string(1) "0" ["sticky"]=> string(1) "0" ["locked"]=> string(1) "0" } ["type"]=> string(2) "->" ["args"]=> array(1) { [0]=> &string(13) "views=views+1" } } }query: update docking.thread set views=views+1 where id=41