So, boinc_finish was called and return value is 68.
And then BOINC interprets it through own list of errors.
But the 68 error is NOT from the science application. It is from BOINC itself before the science application is called.
BOINC output below.
<core_client_version>7.16.11</core_client_version>
<![CDATA[
<message>
The name limit for the local computer network adapter card was exceeded.
(0x44) - exit code 68 (0x44)</message>
<stderr_txt>
06:27:47 (2764): [normal]: This Einstein@home App was built at: Jul 26 2017 09:32:43
Science application start below.
06:27:47 (2764): [normal]: Start of BOINC application 'projects/einstein.phys.uwm.edu/hsgamma_FGRP5_1.08_windows_intelx86__FGRPSSE.exe'.
Not sure it's correct interpretation of stderr sequence.
BOINC client constructs final output so it can insert own text before science app output with no problems (and own text can be due to science app output, not precede it in time).
I think last string (from my own stderr) supports this.
01:49:30 (924): [normal]: done. calling boinc_finish(68).
01:49:30 (924): called boinc_finish
So, app finished in usual way, making boinc_finish call. But supplied error code is 68 instead of 0 (normal one).
Nevertheless host rebooting could be one of viable steps for error elimination.
I'll try this on own host. Next will attempt project reset.
Thank you for your comments and deep investigative work. It's good to know that I'm not alone in this error mode. I have learned a bunch reading this thread (3X!), yet I only vaguely understand some of it.
As Keith stated before: "You will have to enlist somebody with a lot more knowledge than I can provide." If Keith has admitted that he doesn't have enough knowledge, then I certainly don't and won't ever have.
Raistmer* stated early on: "Perhaps, worth to reset project. This will cause re-downloading of all (including that one) files and maybe will solve issue (maybe not if corrupted file was used for CRC computations indeed, in that case only project staff can solve this)." I have considered doing this before posting initially, even to the point of starting over (i.e.: reset, delete BOINC entirely, reboot and reload BOINC) and see if anything changes in regards to my errors.
As I've stated before, I'm relatively new at this, having signed up with SETI first in Oct, 2017, and Einstein in Jan 2018. I have much to learn, and I am doing just that.
Moving forward, I do hope that Bernd and some of his staff will look into this. I know that he has a lot on his plate right now with trying to get aged servers upgraded and what not. I'll just keep plugging along until it one day miraculously get fixed.
Unless anyone else has any comments or critiques of the subject, I will consider this case closed (for now).
From the previous post by Bernd, he fixed the issue and it is not a problem anymore.
If you rename the JPLEPH.405 file to JLEPH.405.bak the host should redownload the file since the application won't be able to find it with its different name.
The filename and its location on the server is specified in the client_state.xml file for the application.
Or to be perfectly safe, reset the project and it will redownload all the necessary files for your proscribed applications.
[Edit] But you are processing valid GR tasks now so you got a good copy of the file already. Problem solved by Bernd long ago.
Just continue crunching for Einstein as you normally would.
From the previous post by Bernd, he fixed the issue and it is not a problem anymore.
If you rename the JPLEPH.405 file to JLEPH.405.bak the host should redownload the file since the application won't be able to find it with its different name.
The filename and its location on the server is specified in the client_state.xml file for the application.
Or to be perfectly safe, reset the project and it will redownload all the necessary files for your proscribed applications.
[Edit] But you are processing valid GR tasks now so you got a good copy of the file already. Problem solved by Bernd long ago.
Just continue crunching for Einstein as you normally would.
I let the system 'rest' while I did nothing with it, then checked the <client_state.xml> file today, dated 02/17/2021 @ 1:02PM (according to Windows10), and the file JPLEPH.405 was present. That's all well and good, though I have absolutely no idea what the file is for or for what purpose I would have done the exercise.
And yes, I am continuing to crunch away on Einstein, as well as Milkyway and Universe. Though I do have one or more noobie questions to ask...
..... and the file JPLEPH.405 was present. That's all well and good, though I have absolutely no idea what the file is for or for what purpose I would have done the exercise.
IIRC : That file name stands for Jet Propulsion Laboratory Emphemeris. This contains data about our solar system bodies locations at given times, in particular it's centre of mass ( barycentre ) as the work units' calculations/results are always considered from that frame of reference. It's a relativity thingy.
Cheers, Mike.
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal
..... and the file JPLEPH.405 was present. That's all well and good, though I have absolutely no idea what the file is for or for what purpose I would have done the exercise.
IIRC : That file name stands for Jet Propulsion Laboratory Emphemeris. This contains data about our solar system bodies locations at given times, in particular it's centre of mass ( barycentre ) as the work units' calculations/results are always considered from that frame of reference. It's a relativity thingy.
Cheers, Mike.
Thank you Mike for your explanation, I would have never guessed that in a million years.
Raistmer* wrote: In my
)
But the 68 error is NOT from the science application. It is from BOINC itself before the science application is called.
<core_client_version>7.16.11</core_client_version>
<![CDATA[
<message>
The name limit for the local computer network adapter card was exceeded.
(0x44) - exit code 68 (0x44)</message>
<stderr_txt>
06:27:47 (2764): [normal]: This Einstein@home App was built at: Jul 26 2017 09:32:43
Science application start below.
06:27:47 (2764): [normal]: Start of BOINC application 'projects/einstein.phys.uwm.edu/hsgamma_FGRP5_1.08_windows_intelx86__FGRPSSE.exe'.
Not sure it's correct
)
Not sure it's correct interpretation of stderr sequence.
BOINC client constructs final output so it can insert own text before science app output with no problems (and own text can be due to science app output, not precede it in time).
I think last string (from my own stderr) supports this.
So, app finished in usual way, making boinc_finish call. But supplied error code is 68 instead of 0 (normal one).
Nevertheless host rebooting could be one of viable steps for error elimination.
I'll try this on own host. Next will attempt project reset.
This error has been discussed
)
This error has been discussed before a couple of times, here's one from before Christmas: https://einsteinathome.org/content/cpu-tasks-error-out-after-12-seconds#comment-181786 If you scroll little down from that post you'll find that Bernd took the blame for that one.
Harri Liljeroos wrote:This
)
Haha, just as usual. All was already invented by the Ancient Greeks, one just need to read :)
Thanks for link!
Good detective work. What was
)
Good detective work. What was confusing me is that error 68 is not mentioned at all in the BOINC error codes.
https://boinc.mundayweb.com/wiki/index.php?title=BOINC_Client_Errors_and_Error_Codes
So, the problem really is that the JLEPH file is corrupted from the server.
Rename the file and let the hosts get a new good copy is the solution.
I guess I was just lucky I never got hit with the bad file download.
Gentlemen, Thank you for
)
Gentlemen,
Thank you for your comments and deep investigative work. It's good to know that I'm not alone in this error mode. I have learned a bunch reading this thread (3X!), yet I only vaguely understand some of it.
As Keith stated before: "You will have to enlist somebody with a lot more knowledge than I can provide." If Keith has admitted that he doesn't have enough knowledge, then I certainly don't and won't ever have.
Raistmer* stated early on: "Perhaps, worth to reset project. This will cause re-downloading of all (including that one) files and maybe will solve issue (maybe not if corrupted file was used for CRC computations indeed, in that case only project staff can solve this)." I have considered doing this before posting initially, even to the point of starting over (i.e.: reset, delete BOINC entirely, reboot and reload BOINC) and see if anything changes in regards to my errors.
As I've stated before, I'm relatively new at this, having signed up with SETI first in Oct, 2017, and Einstein in Jan 2018. I have much to learn, and I am doing just that.
Moving forward, I do hope that Bernd and some of his staff will look into this. I know that he has a lot on his plate right now with trying to get aged servers upgraded and what not. I'll just keep plugging along until it one day miraculously get fixed.
Unless anyone else has any comments or critiques of the subject, I will consider this case closed (for now).
Proud member of the Old Farts Association
From the previous post by
)
From the previous post by Bernd, he fixed the issue and it is not a problem anymore.
If you rename the JPLEPH.405 file to JLEPH.405.bak the host should redownload the file since the application won't be able to find it with its different name.
The filename and its location on the server is specified in the client_state.xml file for the application.
Or to be perfectly safe, reset the project and it will redownload all the necessary files for your proscribed applications.
[Edit] But you are processing valid GR tasks now so you got a good copy of the file already. Problem solved by Bernd long ago.
Just continue crunching for Einstein as you normally would.
Keith Myers wrote: From the
)
I let the system 'rest' while I did nothing with it, then checked the <client_state.xml> file today, dated 02/17/2021 @ 1:02PM (according to Windows10), and the file JPLEPH.405 was present. That's all well and good, though I have absolutely no idea what the file is for or for what purpose I would have done the exercise.
And yes, I am continuing to crunch away on Einstein, as well as Milkyway and Universe. Though I do have one or more noobie questions to ask...
Proud member of the Old Farts Association
George wrote:..... and the
)
IIRC : That file name stands for Jet Propulsion Laboratory Emphemeris. This contains data about our solar system bodies locations at given times, in particular it's centre of mass ( barycentre ) as the work units' calculations/results are always considered from that frame of reference. It's a relativity thingy.
Cheers, Mike.
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal
Mike Hewson wrote: George
)
Thank you Mike for your explanation, I would have never guessed that in a million years.
Cheers to you, mate!
Proud member of the Old Farts Association