Computers not connecting to project
14 Jan 2024 13:55:02 UTC
Topic 230616
(moderation:
I am suddenly getting this on two of four computers I have at home. They no longer are connecting to Einstein, but do connect to other projects.
Any ideas as to how to correct this?
All are running the latest Linux Mint and the same version of nvidia drivers. they were running fine and then suddenly this.
Sun 14 Jan 2024 07:42:39 AM CST | Einstein@Home | Error in request message: no end tag
Orange Kid wrote: I am
)
For me the key is to keep trying, there are innumerable reasons why it may not be connecting to Einstein, 10K other people might be trying to do the same thing right now, someone could be trying to block the connection between them and you etc etc etc. I have 17 pc's here at home and they had some serious problem trying to connect when I only had a 500MBps connecytion but because my cable company switched me to streaming only I upgraded to 2GBBps and all my pc's are now connectiong to everything like crazy!! Simply put my problem was too many pc's and not a big enough pipe to send the data thru so it was not connecting, and yes I sometimes got the same messages you are getting.
Orange Kid wrote:.... Sun 14
)
The error message seems quite specific so you should check to see exactly what was in a failed scheduler request.
Whenever your boinc client communicates with the project, a copy of the message is kept in a file called 'sched_request_einstein.phys.uwm.edu.xml' in the BOINC client directory. There is a lot of stuff in that file - details of results being sent, requests for more work, etc. The very last part of the message starts with the tag <other_results> below which is a complete listing of all tasks that your host currently has on board. Each such task has a <other_result> ... </other_result> subsection so the project servers will know if you're missing anything you are supposed to have.
At the end of all that (could be quite lengthy if you have lots of tasks) there will be two closing tags. These should be </other_results> which closes off the section reporting all your tasks, followed by </scheduler_request> which closes off the entire request message itself. I'm guessing (I haven't seen this particular message before) that one of those two closing tags might be missing (or malformed) on a scheduler request that results in the error message you describe. If the final two are present and correct, look through the whole file to check that every opening tag (the ones without a slash) is accompanied by a proper closing tag (the same name with a slash in front of the name). Check for any discrepancy at all.
If your scheduler request seems OK, post more lines of context from the event log to see if there is something else that stands out from all the stuff your client is reporting. Have you tried restarting the boinc client and looking in detail at the startup messages for any further information? The full scheduler reply, 'sched_reply_einstein.phys.uwm.edu.xml' is also kept and maybe there is more about the problem in that file.
Cheers,
Gary.
I have five hosts, four of
)
I have five hosts, four of which are in current use for EIN. One host, 13157651, is showing on this site as last communicating with EIN on 20 Feb. The other hosts are showing connection is being made. This host is showing production, is showing uploading completed work, and is showing downloading of new work in the communication log. Completed and verified production is showing Feb 19--341,720...Feb 22--94,661...Feb 24---46,811....and Feb 25--32,673, which may be when the older work was validated. This host has 10 days of work pending and shows it is doing the calculations as needed.
Final part of the puzzle is that the other hosts are showing normal communication.
James Bradshaw wrote: I have
)
Hi James,
I'll start with the basics... On your host computer #13157651, have you been into the preferences lately?
If you're into the preferences, you must have the project preferences match the computing preferences for the SAME venue, and the same venue must be present for both of the web pages before you save them down on the bottom left of the page. Then don't forget to UPDATE Einstein on this particular computer in the Boinc Manager.
Please let us know if this helps or not, and we'll go from there if needed.
Proud member of the Old Farts Association
James Bradshaw wrote:I have
)
The last contact link for that host ID shows a normal return of a completed task and the sending of a new one. The tasks page on the website shows there have been no further returned results or new tasks downloaded after that date.
If you can see ongoing completion and uploading of work together with downloading of new work in BOINC Manager on the local machine, my immediate thought would be that the host ID of the machine has changed somehow and the new ID must be under a different user name. To confirm if this has somehow happened, just look in the state file (client_state.xml in the BOINC directory - don't make any changes) using something like Windows notepad and check to see (for the Einstein project) if there is an entry such as the example below:-
<hostid>13157651</hostid>If the number isn't as above, then that would explain why 13157651 shows no recent activity. You should also search for <user_name> to see what account the machine is now reporting under. It can't be your normal account since there is no new host ID with the same hardware (eg, 2080 Ti GPU) now listed there.
Cheers,
Gary.
Appreciate all the comments.
)
Appreciate all the comments. Yes, am trying to update all to see if that solves it. Gary, I am also trying to follow through on your suggestions. I am not yet able to find or get into the client_state.xml in the BOINC directory. I am trying to work through my lack of computer skills. Don't give up on me....smile
Appreciate all the comments.
)
Appreciate all the comments. Yes, am trying to update all to see if that solves it. Gary, I am also trying to follow through on your suggestions. I am not yet able to find or get into the client_state.xml in the BOINC directory. I am trying to work through my lack of computer skills. Don't give up on me....smile
James Bradshaw
)
The Boinc directory in Windows is in c:\ program data\boinc you may have to unhide the Program data directory if you never have before, to do it go into File Explorer, click view and over to the right is a check box to show 'hidden items' put a check mark in that box and it should show up.
mikey schrieb: The Boinc
)
It's "hidden" because you may don't want to open or edit BOINC's xml files accidentally. You can type the full path:
directly into Windows Explorer top adress line and it will find and display the client_state.xml, even if the folder or files are “hidden” in Windows. One should probably make sure to always exit (shutdown) BOINC client before opening or editing this file in Windows (to not interfere with the current progress state of tasks). The builtin Windows "Editor" (notepad.exe) blocks opened files from writing by a another process (different than other 3rd party editors or e.g. editor tools in UNIX ... Linux). The BOINC client has to write this file continuously with every status change (request new work, upload tasks, task finished, task paused, ...).
Scrooge McDuck wrote:... One
)
Whilst that's certainly 'best pratice', it's actually not that easy to damage the state file.
On startup, BOINC loads the state file into memory and makes its updates there. Periodically, BOINC refreshes the disk copy from the latest 'in core' copy. If a user manages to make a change to the disk copy, it very quickly gets reverted when BOINC next refreshes the disk copy. There are also mechanisms in place to guard against state file corruption from a system crash in the middle of writing the latest in-core copy to disk.
Also, the Linux text editor I use (kwrite) does warn if the disk version of a file I have open happens to change whilst browsing. I remember an incident when I made (and saved) a quick change to a DCF value in a state file where I thought the client wasn't running. When I discovered the client was running, I also found that the change I'd made had already been 'corrected' by the client, with no adverse side effects :-).
Cheers,
Gary.