Gamma-Ray pulsar #5 stops

Well, if you suspend computation then they should stop and they should say their stopped.
If you then resume computations then they should get going again. If not try to ascertain if they consume any resources CPU/GPU. If your running Windows then open "Task manager" (if you get a window with minimal info then click "More details"" and check for a process with FGRP5 or something similar in it, does it show any CPU usage?

To get the tasks going again try to restart Boinc or reboot the computer.

I think most of us who are willing to help are confused too! :-).

You need to remember that we aren't looking over your shoulder, seeing everything you do and watching the changing information on your screen as a result of changes you make.

Your computers are 'hidden' (standard default setting these days due to the European GDPR privacy regulations) so it is very helpful if you at least supply a computer ID for the machine showing the problems, even if you want to keep your full list private.  If you don't do that, people wont feel competent to fully understand the problem and diagnose it.

Without being able to see the details, you need to supply much more information about your system.  You can easily find your computer ID by going to your account page on the website and following the link to your particular computer.  By supplying that ID, you save having to supply all the hardware/software/completed results details that make diagnosis easier to do.

Here are some answers to other points you raise.

What exactly do you mean by this. Did you suspend computation of one or more tasks and if so, why?  I suspect you may actually mean that you stopped BOINC itself (which is different from suspending computation) and that when you (at some later stage) restarted BOINC, the progress of tasks changed to lower values or perhaps even went right back to zero.

When BOINC is running and computation is not suspended, you should see all tasks showing incremental progress at reasonably regular intervals, usually every few seconds but certainly no longer than a minute or two, even if the computer is quite slow.  If progress reaches some point and then stops completely for an extended period, there is something else interfering.  What do you use for the computing preference question, "Suspend when computer is in use"?  What about the question, "Leave non-GPU tasks in memory while suspended"?   Sometimes, behaviour that looks like a problem may just be due to inappropriate preference settings.

Apart from the progress % regularly increasing, you can have problems with losing progress if a particular task just happens not to create checkpoints very regularly.  There are some data series where the checkpoints could be more than an hour apart.  You could lose significant progress when BOINC shuts down or if a task is suspended without being kept in memory.  The 'properties' page for a task will list the CPU time since the last checkpoint was written.  This is how much you could lose on that task if BOINC shuts down at this point without being kept in memory.

A task is not "obviously running" if it's not making regular incremental progress.  A task will run more efficiently if you can allow it not to be interrupted unnecessarily.  If running tasks are interfering with your normal use of the computer, the most efficient thing to do is limit the number of cores BOINC is allowed to use.  If your computer is relatively modern, and if your normal activities are mainly office/browsing/email type use, you should hardly notice BOINC running in the background.

If you want to experiment to see if BOINC is having much impact, try reducing the number of cores incrementally until you find a setting that works for you.  As an example, if your machine had 8 cores, you could reduce the % of cores that BOINC uses from 100% to 87.5% to 75%, etc, until you are happy with the result.

The first line shows how much CPU time will be lost if you stop the task at that point (over an hour).  Ideally, if you want to stop crunching without losing progress, you might try to choose a stage where that number is reasonably low.

Usually checkpoints are created fairly regularly.  As an example, the properties info you provided shows that the data series was LATeah0055F.dat.  Because your info is not available, I found a task from one of my hosts for that same data series.  By clicking on the task ID link for that task on the website (you could do exactly the same for any of your tasks) I scrolled down in the page of info to find the "STDERR.TXT" heading and from what was there, I extracted the following snip which shows the first two checkpoints being written.

% fft_size: 67108864 (0x4000000, 2^26); alloc: 268435464
% Sky point 1/79
% Creating FFT (3.3.6-pl2 22109fa) plan.
% Starting semicoherent search over f0 and f1.
% nf1dots: 56 df1dot: 1.84974169e-15 f1dot_start: -1e-13 f1dot_band: 1e-13
% Filling array of photon pairs
........................................................
% C 1 0
% Sky point 2/79
% Starting semicoherent search over f0 and f1.
% nf1dots: 56 df1dot: 1.84974169e-15 f1dot_start: -1e-13 f1dot_band: 1e-13
% Filling array of photon pairs
........................................................
% C 2 0

There are 79 'Sky points' being analysed (line 2).
The value of the parameter nf1dots is 56 (line 5).
This means that each sky point will have 56 calculation loops to be performed.
As each of these is completed, a 'dot' is added to the row of dots in line 7. (Count them if you like - there are 56.
When the sky point is finished,  a checkpoint is written - % C 1 indicates the first checkpoint (line 8).
Then the calculation loops move on to the 2nd sky point - 2/79 and the process repeats.

Since there are 79 sky points there will be 79 checkpoints and this will occur regularly for every 90/79=1.139% of progress.  This means that when the progress % shows 1.139%, 2.278%, 3.418%, 4.557%, .... etc, you can know a checkpoint has been written without even checking the properties page.

With other data files (and perhaps even within the one data file - I don't know) I've seen examples where the sky points are very low (eg 8) and the nf1dots is very high (about 553 from memory).  The amount of computation in a task can probably be roughly estimated from sky points X nf1dots - 79x56=4424 and 8x553=4424 - which I guess is why the crunch time seems reasonably constant even if the checkpoint time is not.  With 8 sky points, a checkpoint would be written every 11.25% of progress.

In talking about when checkpoints are created, I'm reminded about a computing preference setting, "Request tasks to checkpoint at most every: ".  You haven't changed that from the default value of 60 secs have you by any chance?

A lot of the above is an educated guess on my part but I'm sharing it in the hope it might help you understand why it's useful to allow crunching to proceed without constant interruption if possible.

With regard to your concern about the name of the executable, the intelx86 part refers to the architecture that the executable is designed to run on and not the processor brand.  Both Intel and AMD make processors that comply with the basic x86 (or x86_64) architecture.  The same application runs on both brands.

If these sorts of comments don't tally with what you are actually seeing, please take some time to explain exactly what you do see.

I'll chime in and I'm sure Gary will be back in a while to fill in some more details.

That's a good indication that the jobs are actually running and processing data. (Unless they've gotten stuck in a loop and that rarely happens)

This one is easy to explain if one knows a bit about how Boinc works.
A few years ago Boinc was changed to show "pseudo progress" if a task doesn't report progress to Boinc in a timely manner. The change was made as many volunteers thought that tasks didn't work if the progress percentage didn't increase often enough. So now Boinc simulates progress until the tasks reports progress. It will increase towards but never reach 100% complete. Then when the task finally report progress Boinc will reset to the reported progress!
This can be really confusing to new volunteers.

As the tasks here at Einstein@home only reports progress when a checkpoint is written then the progress update frequency will vary between tasks and can for some tasks be quite long apart, more than 1 hour apart on a slower task/host.

I do feel your pain!