Chris,
Sorry I keep using tabs/enter and send incomplete messages.
I just noticed your comment/question about web proxies. I use one in my hardware firewall. It is in IPCop 1.3.0. The firewall manages the ATT connection.
The rest of my system is AMD 1.4 W98SE and 4.25.
I switched from 4.19 a couple of days ago after a system crash. I did not see this mismatch in WUs at all prior to the switch to 4.25.
Joe B
>....I did not see this mismatch in WUs at all prior
>to the switch to 4.25.
I'm running v4.19 and I'm still having this problem - got two recent "phantom" WU's working their way through my results right now....result ID's #1678384 and #1767610 to be precise (both coinciding with occasions when my host tried contacting the Einstein servers and, claimed, it received no response).
Anyway, if you read above the powers that be are aware of this and are working on it. In the meantime, just ignore it....
First, we've identified one mode where these phantom WU's will be assigned to your computers-the Content-Length issue with the 4.19 client. However, as Bruce's FAQ entry (7th from the end) states, there are many reasons why these WU's became phantom. Any communications failure once the server has sent the WU and before the client has successfully accepted it will cause this issue. I think it's too early to assign your issue to the 4.25 client.
I've looked at your computers and WU results assigned to them, as far as I can as a user. It appears that you have not completed any WU's since upgrading, so it is not possible for me to see which WU's are phantoms and which are not.
It is possible that the way you upgraded the client(s) may have lead to the phantom WU's--do you know if the phantom WU's were sent before or after the upgrade? Are or were you having other network connectivity issues?
It will be interesting to track this to verify that the issue with 4.19 is indeed fixed in 4.25.
Also, I don't believe that your hardware proxy will allow you to filter out the Content-Length field in HTTP headers, so I suspect it will not do what I need. Many proxies in fact do the opposite--they add the Content-Length field in the process of rewriting the headers, thus triggering the bug in 4.19 clients.
You say you switched from CC v4.19 to CC v4.25. Versions 4.22 and later of the core client software require all cruncher files to be signed. As far as I know, E@H hasn't yet updated and signed it's files for v4.2x use.
As for seeing the phantom WUs. This is a byproduct of the CC attempting to download WUs with the cruncher apps. What you're seeing here is that several WUs have managed to finish downloading before the cruncher's signature is verified and found to be at fault. Seeing as there isn't a cruncher to crunch the WUs, the files are deleted and details are sent back to the project servers as much as to say that these failed to download. If you don't catch this behaviour quick enough, it will try again after a timeout period. Of course this will fail in an identical fashion, and will keep failing until the required signatures are present. This in turn, will build up a shedload of "phantom" WUs that never make it to your machine.
I have managed to get around this by installing v4.19 of the BOINC CC and attaching to my projects as normal, making sure that crunchers and work are downloaded for each before I continue to the next step. I then exit the CC and backup the installation directory. After doing this, I un-install v4.19 and install v4.2x TO THE SAME LOCATION THAT v4.19 RESIDED ("C:\Program Files\BOINC")
The directory that holds the project's crunchers and work should be intact after this and after the usual upgrade benchmark twaddle, crunching will continue as normal using the un-signed crunchers.
Chis,
I have completed 4 non-zero WUs in the past days. They show up in "Results for user" as:
1712126 465533 9 Mar 2005 23:28:26 UTC 11 Mar 2005 0:47:36 UTC Over Success Done 35,740.56 68.46 pending
1703658 463582 9 Mar 2005 23:28:26 UTC 10 Mar 2005 15:50:17 UTC Over Success Done 35,026.27 67.09 pending
1722245 467853 9 Mar 2005 23:28:26 UTC 11 Mar 2005 11:25:50 UTC Over Success Done 38,305.51 73.38 pending
1731802 470063 9 Mar 2005 23:28:26 UTC 11 Mar 2005 18:09:05 UTC Over Success Done 36,333.62 69.60 pending
I had no trouble with 4.19 and only have had it with 4.25. Might be a coincidence. But I do not stay on the internet any longer than necessary - it ties up my phone line. I do not check to see what Boinc is doing before I disconnect. Should I suspend Boinc before disconnecting? How about before my daily reboot? - good ole W98.
JoeB
> You say you switched from CC v4.19 to CC v4.25. Versions
>4.22 and later of the core client software require all
>cruncher files to be signed. As far as I know, E@H hasn't
>yet updated and signed it's files for v4.2x use.
Just wondering, do you or anyone else know whether this issue has been addressed yet?
I'm wondering about updating to BOINC v4.25 but am reluctant to do so until I know there won't be any problems caused by the upgrade....
> You say you switched from CC v4.19 to CC v4.25. Versions 4.22 and later of the
> core client software require all cruncher files to be signed. As far as I
> know, E@H hasn't yet updated and signed it's files for v4.2x use.
Could you please provide more details (or a link)? What is it that we need to do?
> > You say you switched from CC v4.19 to CC v4.25. Versions 4.22 and later
> of the
> > core client software require all cruncher files to be signed. As far as
> I
> > know, E@H hasn't yet updated and signed it's files for v4.2x use.
>
> Could you please provide more details (or a link)? What is it that we need to
> do?
>
> Bruce
>
>
The einstien app is properly signed. The user may need to do a project reset or detach and reattach to clear out old signatures though.
Chris, Sorry I keep using
)
Chris,
Sorry I keep using tabs/enter and send incomplete messages.
I just noticed your comment/question about web proxies. I use one in my hardware firewall. It is in IPCop 1.3.0. The firewall manages the ATT connection.
The rest of my system is AMD 1.4 W98SE and 4.25.
I switched from 4.19 a couple of days ago after a system crash. I did not see this mismatch in WUs at all prior to the switch to 4.25.
Joe B
Joe B
Hi Joe, >....I did not
)
Hi Joe,
>....I did not see this mismatch in WUs at all prior
>to the switch to 4.25.
I'm running v4.19 and I'm still having this problem - got two recent "phantom" WU's working their way through my results right now....result ID's #1678384 and #1767610 to be precise (both coinciding with occasions when my host tried contacting the Einstein servers and, claimed, it received no response).
Anyway, if you read above the powers that be are aware of this and are working on it. In the meantime, just ignore it....
TTFN - Pete.
JoeB, First, we've
)
JoeB,
First, we've identified one mode where these phantom WU's will be assigned to your computers-the Content-Length issue with the 4.19 client. However, as Bruce's FAQ entry (7th from the end) states, there are many reasons why these WU's became phantom. Any communications failure once the server has sent the WU and before the client has successfully accepted it will cause this issue. I think it's too early to assign your issue to the 4.25 client.
I've looked at your computers and WU results assigned to them, as far as I can as a user. It appears that you have not completed any WU's since upgrading, so it is not possible for me to see which WU's are phantoms and which are not.
It is possible that the way you upgraded the client(s) may have lead to the phantom WU's--do you know if the phantom WU's were sent before or after the upgrade? Are or were you having other network connectivity issues?
It will be interesting to track this to verify that the issue with 4.19 is indeed fixed in 4.25.
Also, I don't believe that your hardware proxy will allow you to filter out the Content-Length field in HTTP headers, so I suspect it will not do what I need. Many proxies in fact do the opposite--they add the Content-Length field in the process of rewriting the headers, thus triggering the bug in 4.19 clients.
Chris.
You say you switched from CC
)
You say you switched from CC v4.19 to CC v4.25. Versions 4.22 and later of the core client software require all cruncher files to be signed. As far as I know, E@H hasn't yet updated and signed it's files for v4.2x use.
As for seeing the phantom WUs. This is a byproduct of the CC attempting to download WUs with the cruncher apps. What you're seeing here is that several WUs have managed to finish downloading before the cruncher's signature is verified and found to be at fault. Seeing as there isn't a cruncher to crunch the WUs, the files are deleted and details are sent back to the project servers as much as to say that these failed to download. If you don't catch this behaviour quick enough, it will try again after a timeout period. Of course this will fail in an identical fashion, and will keep failing until the required signatures are present. This in turn, will build up a shedload of "phantom" WUs that never make it to your machine.
I have managed to get around this by installing v4.19 of the BOINC CC and attaching to my projects as normal, making sure that crunchers and work are downloaded for each before I continue to the next step. I then exit the CC and backup the installation directory. After doing this, I un-install v4.19 and install v4.2x TO THE SAME LOCATION THAT v4.19 RESIDED ("C:\Program Files\BOINC")
The directory that holds the project's crunchers and work should be intact after this and after the usual upgrade benchmark twaddle, crunching will continue as normal using the un-signed crunchers.
Hope this helps.
Chis, I have completed 4
)
Chis,
I have completed 4 non-zero WUs in the past days. They show up in "Results for user" as:
1712126 465533 9 Mar 2005 23:28:26 UTC 11 Mar 2005 0:47:36 UTC Over Success Done 35,740.56 68.46 pending
1703658 463582 9 Mar 2005 23:28:26 UTC 10 Mar 2005 15:50:17 UTC Over Success Done 35,026.27 67.09 pending
1722245 467853 9 Mar 2005 23:28:26 UTC 11 Mar 2005 11:25:50 UTC Over Success Done 38,305.51 73.38 pending
1731802 470063 9 Mar 2005 23:28:26 UTC 11 Mar 2005 18:09:05 UTC Over Success Done 36,333.62 69.60 pending
I had no trouble with 4.19 and only have had it with 4.25. Might be a coincidence. But I do not stay on the internet any longer than necessary - it ties up my phone line. I do not check to see what Boinc is doing before I disconnect. Should I suspend Boinc before disconnecting? How about before my daily reboot? - good ole W98.
JoeB
Joe B
Hi Gareth, > You say you
)
Hi Gareth,
> You say you switched from CC v4.19 to CC v4.25. Versions
>4.22 and later of the core client software require all
>cruncher files to be signed. As far as I know, E@H hasn't
>yet updated and signed it's files for v4.2x use.
Just wondering, do you or anyone else know whether this issue has been addressed yet?
I'm wondering about updating to BOINC v4.25 but am reluctant to do so until I know there won't be any problems caused by the upgrade....
Thanks.
TTFN - Pete.
Oh, was also wondering
)
Oh, was also wondering whether the developers want us to keep reporting occurences of these "phantom WUs" or not?
I ask as I've had another during the last few days, ID#: 536318.
Thanks.
TTFN - Pete.
> You say you switched from
)
> You say you switched from CC v4.19 to CC v4.25. Versions 4.22 and later of the
> core client software require all cruncher files to be signed. As far as I
> know, E@H hasn't yet updated and signed it's files for v4.2x use.
Could you please provide more details (or a link)? What is it that we need to do?
Bruce
Director, Einstein@Home
> > You say you switched from
)
> > You say you switched from CC v4.19 to CC v4.25. Versions 4.22 and later
> of the
> > core client software require all cruncher files to be signed. As far as
> I
> > know, E@H hasn't yet updated and signed it's files for v4.2x use.
>
> Could you please provide more details (or a link)? What is it that we need to
> do?
>
> Bruce
>
>
The einstien app is properly signed. The user may need to do a project reset or detach and reattach to clear out old signatures though.
BOINC WIKI
BOINCing since 2002/12/8
Hi, > The einstien app
)
Hi,
> The einstien app is properly signed. The user may need
>to do a project reset or detach and reattach to clear out
>old signatures though.
Thanks for the info, that's exactly what I needed to know.
TTFN - Pete.