What could cause "error in computing"?

Keith Myers
Keith Myers
Joined: 11 Feb 11
Posts: 4,897
Credit: 18,445,591,541
RAC: 5,898,419

Raistmer* wrote: In my

Raistmer* wrote:

In my understanding 

68 comes from science app itself:

14:33:17 (55951): [normal]: done. calling boinc_finish(68).

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'.


 

Raistmer*
Raistmer*
Joined: 20 Feb 05
Posts: 208
Credit: 181,029,317
RAC: 10,601

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.

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.

 

Harri Liljeroos
Harri Liljeroos
Joined: 10 Dec 05
Posts: 4,196
Credit: 3,114,600,342
RAC: 1,838,035

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.

Raistmer*
Raistmer*
Joined: 20 Feb 05
Posts: 208
Credit: 181,029,317
RAC: 10,601

Harri Liljeroos wrote:This

Harri Liljeroos wrote:

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.

Haha, just as usual. All was already invented by the Ancient Greeks, one just need to read :)

Thanks for link!

 

Keith Myers
Keith Myers
Joined: 11 Feb 11
Posts: 4,897
Credit: 18,445,591,541
RAC: 5,898,419

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.

 

GWGeorge007
GWGeorge007
Joined: 8 Jan 18
Posts: 3,000
Credit: 4,926,044,438
RAC: 129,282

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).

George

Proud member of the Old Farts Association

Keith Myers
Keith Myers
Joined: 11 Feb 11
Posts: 4,897
Credit: 18,445,591,541
RAC: 5,898,419

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.

 

GWGeorge007
GWGeorge007
Joined: 8 Jan 18
Posts: 3,000
Credit: 4,926,044,438
RAC: 129,282

Keith Myers wrote: From the

Keith Myers wrote:

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...

George

Proud member of the Old Farts Association

Mike Hewson
Mike Hewson
Moderator
Joined: 1 Dec 05
Posts: 6,579
Credit: 306,922,947
RAC: 160,559

George wrote:..... and the

George wrote:

..... 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

GWGeorge007
GWGeorge007
Joined: 8 Jan 18
Posts: 3,000
Credit: 4,926,044,438
RAC: 129,282

Mike Hewson wrote: George

Mike Hewson wrote:

George wrote:

..... 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.

Cheers to you, mate!

George

Proud member of the Old Farts Association

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.