Don't forget that D41.12 produces worse results than D41.13/14.
Yes, sure :) But I recived only 2 invalid results that not affect science (cause no new WUs were issued) and no computation errors on this PC.
So i just keeped D41.12 till reliable statistics were gathered. Now on S41.07 - results in corresponding thread (S-version faster on this PC).
My machine (Barton 2500+ - Win98SE) has some "difficulties" with wus z1_1384.0 but look at this one running D41.13 :
...
cpu time : 21,812.38 sec.
(usually ~ 3,500 sec)
Probably and other task used your CPU for ~18000 sec during this calculation just the Win98 (Win95,WinMe) wasn't able to calculate the task times correctly.
My machine (Barton 2500+ - Win98SE) has some "difficulties" with wus z1_1384.0 but look at this one running D41.13 :
...
cpu time : 21,812.38 sec.
(usually ~ 3,500 sec)
Probably and other task used your CPU for ~18000 sec during this calculation just the Win98 (Win95,WinMe) wasn't able to calculate the task times correctly.
Another possibility is that the timer was not even measuring time.
One of my two Win98SE machines has timing accuracy failures of two severe types.
1. Once in a while it just starts double counting time. You can set and watch a WU in progress and just see the CPU time column in BOINCmgr go up ten seconds for each elapsed five seconds. In my experience, if I exit BOINCmgr and restart before the WU is complete, the "correct" CPU time comes back from somewhere, and is reported, but if the WU completes, is uploaded and reported before a restart, the double time goes right on through. It then wreaks havoc on things like Result Duration Correction Factor. I see this fault on one of my two Win98SE machines about once a week, the other seldom if ever.
2. Just once or maybe twice, I've seen the first Win98SE host go a mode of claiming zero CPU time for its work. I saw this just recently on May 6. For example: zero CPU time result
In this case the result validated and I got normal credit--so just the time was wrong.
I can also affirm that I weekly observe the case akosf mentions here. Each week both Win98SE machines do a Norton virus scan check, and the result in progress claims something like an extra hour of CPU time.
Win98SE and accurate BOINC cpu time don't go together, but these two old Pentium III's running akosf code are as productive as far more modern machines before akosf.
There was a problem with the validator at the time and they sent the wu back out to 3 more computers. I see that you was granted credit for it. Glad you posted, because you answered an earlier question I had submitted.
Sorry, I should've been more specific. Yes, if you look at the credit for all the machines that worked on that particular wu, it shows "-" in the claimed and granted columns. But if you click on the result ID and scroll down to the claimed and granted credit it will show 10.70 & 34.77 respectively.
Compare on two of my results (as of at this moment): granted and not granted.
RE: RE: Athlon
)
Yes, sure :) But I recived only 2 invalid results that not affect science (cause no new WUs were issued) and no computation errors on this PC.
So i just keeped D41.12 till reliable statistics were gathered. Now on S41.07 - results in corresponding thread (S-version faster on this PC).
My machine (Barton 2500+ -
)
My machine (Barton 2500+ - Win98SE) has some "difficulties" with wus z1_1384.0 but look at this one running D41.13 :
wuid=8140486
computer : 27340
cpu time : 21,812.38 sec.
(usually ~ 3,500 sec)
[
RE: My machine (Barton
)
Probably and other task used your CPU for ~18000 sec during this calculation just the Win98 (Win95,WinMe) wasn't able to calculate the task times correctly.
RE: RE: My machine
)
Another possibility is that the timer was not even measuring time.
One of my two Win98SE machines has timing accuracy failures of two severe types.
1. Once in a while it just starts double counting time. You can set and watch a WU in progress and just see the CPU time column in BOINCmgr go up ten seconds for each elapsed five seconds. In my experience, if I exit BOINCmgr and restart before the WU is complete, the "correct" CPU time comes back from somewhere, and is reported, but if the WU completes, is uploaded and reported before a restart, the double time goes right on through. It then wreaks havoc on things like Result Duration Correction Factor. I see this fault on one of my two Win98SE machines about once a week, the other seldom if ever.
2. Just once or maybe twice, I've seen the first Win98SE host go a mode of claiming zero CPU time for its work. I saw this just recently on May 6. For example:
zero CPU time result
In this case the result validated and I got normal credit--so just the time was wrong.
I can also affirm that I weekly observe the case akosf mentions here. Each week both Win98SE machines do a Norton virus scan check, and the result in progress claims something like an extra hour of CPU time.
Win98SE and accurate BOINC cpu time don't go together, but these two old Pentium III's running akosf code are as productive as far more modern machines before akosf.
First irregularity on this
)
First irregularity on this workunit:
http://einsteinathome.org/workunit/8120674
there this result:
http://einsteinathome.org/task/28917157
Error: Checked, but no consensus yet
Aloha, Uli
RE: First irregularity on
)
There was a problem with the validator at the time and they sent the wu back out to 3 more computers. I see that you was granted credit for it. Glad you posted, because you answered an earlier question I had submitted.
RE: (...) I see that you
)
Unfortunately not, as you can see here: http://einsteinathome.org/workunit/8120674. My computer is No. 7269
Aloha, Uli
RE: RE: (...) I see that
)
Sorry, I should've been more specific. Yes, if you look at the credit for all the machines that worked on that particular wu, it shows "-" in the claimed and granted columns. But if you click on the result ID and scroll down to the claimed and granted credit it will show 10.70 & 34.77 respectively.
Compare on two of my results (as of at this moment): granted and not granted.
Is D41.14 still kind of buggy
)
Is D41.14 still kind of buggy or dare I upgrade to it?
RE: Is D41.14 still kind of
)
I have been using D14.14 on my t-bird 1.2 ghz for some time now. Absolutly no problems at my end. All results have been validated OK.