I was first to bring up RDCF problem see BOINC thread....
Sorry to burst your bubble :), but a user called Bob Guy was probably the first (that I saw anyway) to report the behaviour in this post over on the BOINC boards. That was a couple of weeks earlier than your above-linked report.
The surprising thing is that the behaviour was around for the entire 5.8.x series, was reported many times by many different people but yet the fix didn't make it into the release version 5.8.8. Yes, it is corrected in 5.8.9 but the damage is now done. A whole bunch of people who know nothing about the bug are going to be continuously rediscovering it as they progressively upgrade to the recommended version. All projects' message boards are going to be bombarded with "Why is this happening ....?" type posts until there is a new recommended version to replace 5.8.8.
Hmmm, stange. I have a host running 5.8.0 (at least that's what it calls itself on reports) and the RDCF was fine right up until recently when it developed an issue completely unrelated to BOINC which pretty much spoffed all of its metrics.
Maybe not so strange if you think about the details of the bug. The Bob Guy report clearly stated 5.8.0 and I also reported the same behaviour in 5.8.0 and 5.8.1 which I was trialling at the time.
So why didn't you see the bug ...?
The possible explanation is that the bug manifests itself through the value of DCF being set to the square root of what it really should be. For example if the true DCF is 0.64 the buggy value will be set to sqrt(0.64) = 0.8 and most people would probably notice the difference that this caused in the estimated completion time (ECT) of a "ready to start" result. However if your true DCF was close to unity then the square root is also close to unity (sqrt(0.96) = 0.98) which would give an ECT pretty close to the actual time reported when crunched. This is probably why JM7 said somewhere that if projects got their work unit estimates set properly there wouldn't be a problem, or words to that effect :). I wondered what he was smoking at the time but now I guess I understand - although I don't agree that projects need to have estimates of that precision so as to hide the bug :).
I first reported it in 5.8.3, but had been running 5.8.0 on one of my computers which I didn't monitor to closely. I had skimmed through Jords Thread but decided it was to long, and now having read it its seems that Jord and others thought BobGuy was mistaken.
Shortly after I made that post I contacted JM7 and he said he couldn't see it on his computers and I assume he thought I had changed something else on my computer to cause the effect seen. Or that I was only monitoring projects like Seti with its variable and unpredictably length units. It took me a while to convince him that I was monitoring here at Einstein because the units are reasonably consistent. I even suspended all Seti work just to get greater thoughput. Eventually after a few emails, I made a cc_config file to monitor a few parameters on my main computer, but before I could get back to him or copy the file to my other computer, Dr.A posted on the Devs List that he was aware of the problem and that a fix was to be included asap. I believe, that Dr.A was informed of the problem from WCG, not from anything posted here, Seti or BOINC pages or from JM7, but there I could be wrong.
My RDCFs on Einstein, and Seti Beta before 5.8.n was in the region of 0.5 to 0.6. On seti due to optimised app it was generally below 0.5. Now that I have upgraded to 5.8.9 they are begining to return to these figures having been higher than 0.7.
I also trying 5.8.9, as I
)
I also trying 5.8.9, as I believe I was first to bring up RDCF problem see BOINC thread, so far it looks good, RDCF on three projects now decreasing.
Andy
RE: I was first to bring up
)
Sorry to burst your bubble :), but a user called Bob Guy was probably the first (that I saw anyway) to report the behaviour in this post over on the BOINC boards. That was a couple of weeks earlier than your above-linked report.
The surprising thing is that the behaviour was around for the entire 5.8.x series, was reported many times by many different people but yet the fix didn't make it into the release version 5.8.8. Yes, it is corrected in 5.8.9 but the damage is now done. A whole bunch of people who know nothing about the bug are going to be continuously rediscovering it as they progressively upgrade to the recommended version. All projects' message boards are going to be bombarded with "Why is this happening ....?" type posts until there is a new recommended version to replace 5.8.8.
Cheers,
Gary.
Hmmm, stange. I have a host
)
Hmmm, stange. I have a host running 5.8.0 (at least that's what it calls itself on reports) and the RDCF was fine right up until recently when it developed an issue completely unrelated to BOINC which pretty much spoffed all of its metrics.
Alinator
RE: Hmmm, stange. I have a
)
Maybe not so strange if you think about the details of the bug. The Bob Guy report clearly stated 5.8.0 and I also reported the same behaviour in 5.8.0 and 5.8.1 which I was trialling at the time.
So why didn't you see the bug ...?
The possible explanation is that the bug manifests itself through the value of DCF being set to the square root of what it really should be. For example if the true DCF is 0.64 the buggy value will be set to sqrt(0.64) = 0.8 and most people would probably notice the difference that this caused in the estimated completion time (ECT) of a "ready to start" result. However if your true DCF was close to unity then the square root is also close to unity (sqrt(0.96) = 0.98) which would give an ECT pretty close to the actual time reported when crunched. This is probably why JM7 said somewhere that if projects got their work unit estimates set properly there wouldn't be a problem, or words to that effect :). I wondered what he was smoking at the time but now I guess I understand - although I don't agree that projects need to have estimates of that precision so as to hide the bug :).
Cheers,
Gary.
I first reported it in 5.8.3,
)
I first reported it in 5.8.3, but had been running 5.8.0 on one of my computers which I didn't monitor to closely. I had skimmed through Jords Thread but decided it was to long, and now having read it its seems that Jord and others thought BobGuy was mistaken.
Shortly after I made that post I contacted JM7 and he said he couldn't see it on his computers and I assume he thought I had changed something else on my computer to cause the effect seen. Or that I was only monitoring projects like Seti with its variable and unpredictably length units. It took me a while to convince him that I was monitoring here at Einstein because the units are reasonably consistent. I even suspended all Seti work just to get greater thoughput. Eventually after a few emails, I made a cc_config file to monitor a few parameters on my main computer, but before I could get back to him or copy the file to my other computer, Dr.A posted on the Devs List that he was aware of the problem and that a fix was to be included asap. I believe, that Dr.A was informed of the problem from WCG, not from anything posted here, Seti or BOINC pages or from JM7, but there I could be wrong.
My RDCFs on Einstein, and Seti Beta before 5.8.n was in the region of 0.5 to 0.6. On seti due to optimised app it was generally below 0.5. Now that I have upgraded to 5.8.9 they are begining to return to these figures having been higher than 0.7.
Andy