stderr on 1.28 WUs report running in standalone mode

A bigger snippet gives more of a clue

[09:41:52][5335][INFO ] Application startup - thank you for supporting Einstein@Home!
parse_init_data_file: no end tag
09:41:52 (5335): Can't parse init data file - running in standalone mode

When a BRP4 task starts, BOINC places (mostly links to) data files, executables, etc, that will be needed by the science app in a slot directory (0, 1, 2, ...). The number of these different directories corresponds to the number of threads your CPU/GPU can handle. So if you were doing 4 CPU jobs and 1 GPU job you would be able to find 5 slot directories - 0 to 4. If you browse these slot directories you will see what BOINC has assembled for each particular task. In a slot directory where there is a link to the BRP4 app, you will see a file called init_data.xml.

The above message is indicating that when the science app was started and it tried to read this file, it wasn't happy with what it found. The file is a text file and you can browse it with your favourite simple text editor and you should see the tag at the start and the tag at the end. The error message seems to be indicating that (at least) the end tag is missing. All this is an educated guess but I assume it may be linked to the server overloading problems that were being experienced around the time (2nd September) that particular group of tasks was assigned to that particular host.

Currently, your host is finishing off tasks sent on 2nd Sept and then it will be onto tasks sent much later - 8th/9th September. Your host hasn't reported in for a couple of days (probably because of what is discussed below) so you might like to do an 'update' and send in a bunch of completed tasks. If the problem was anything to do with server overload on 2nd September, maybe the later dated tasks will not be giving this message.

I emphasise that the above is just guesswork. If I'm wrong, hopefully a more knowledgeable person will correct me.

Your tasks are validating and being assigned the correct credit so there's really no need to worry too much about the 0.00 CPU time. The credit claim is a direct result of this but with server assigned credits, it doesn't matter. It would be interesting to see if the later dated tasks have avoided this problem.

There is no reason to think that your BOINC 7.0.29 is causing this. However it is causing another issue. Your other hosts are on BOINC 6.12.x and you have obviously set your two cache settings to something like 0 days and X days respectively which is fine for 6.12.x. However for BOINC 7 you need to think of the first value as a 'low water mark' and the second value as an increment to define a 'high water mark'. So if you had set something like 0/4 for example, BOINC would not ask for new work until the cache was empty and then would get 4 days worth in one big hit. By looking at the dates in your list of tasks this seems to be something like what's happening. The easiest thing for you to do is to set local preferences on just that machine, essentially reversing the two values. If the numbers were say 4/0, BOINC would then maintain a continuous 4 day cache on that machine. Alternatively, you could assign just that machine to a different venue and then still be able to set the preferences for that venue on the website rather than locally.

So if it were my host, I would set local work cache prefs to something like 1/0 to start with (depends on how much work you have left) and gradually increase the first value in stages until you get to the desired cache level. I have this thing called "try to be kind to the server" and I try to ask for modest amounts and let that finish downloading completely before asking again. I know I'm fooling myself, but I try anyway :-). Once you finally get to your full cache setting, you will then only be downloading incrementally from that point onwards.