Missing one of my computers

If you post text like that between [ code ] tags (click the triangle in front of BBCODE HELP to see details) when composing a message it will be a lot easier to read :-).  Also if, before pasting, you click the third last icon at the RH end of the set of controls at the top of the composition window, your paste will happen "as plain text" which may give a more readable result.

I've checked the event log and everything seems normal there.  The task you had belonged to a previous search which is no longer current.  Your computer did contact the server when I checked after your latest post and the result of that contact showed as "not requesting any work" so I'm wondering if you haven't checked your project preferences and selected one of the current CPU searches.  By the look of things, you just need to do that.

If you go to Account -> Preferences -> Project and scroll down until you find the list of Applications, the ones that currently have CPU work are Gamma-ray Pulsar search #5 and Continuous Gravitational Wave search O2 All-Sky.  Select one or both of those, as you prefer, and you should then be able to get some tasks.

The last task you received was back in March, the one you just aborted.  If you had received anything recently, it would have been listed in BOINC Manager and also on the website.  Your machine had no contact with the project after March until you sent back the aborted task.  You can't receive tasks if you don't make contact and make a work request :-).

I can't think of any other way to explain it  Did you ever check to see if it was the same task day after day?  Did you ever check the elapsed time and % progress that was showing for the task?  We are talking about a period of three months.  It seems quite far fetched to imagine that the one task was still not finished after all that time.

I believe that tasks that haven't even started by the deadline do get aborted as soon as the deadline passes.  Tasks that have started are left to continue.  You do get warnings in the event log.  In the snip you posted, here is what the BOINC client said about that task during the re-start.

26.06.2019 21:00:07 | Einstein@Home | Task h1_0330.75_O1C02Cl3In0__O1OD1_330.95Hz_307_0 is 91.07 days overdue; you may not get credit for it. Consider aborting it.

Every time you started your machine, a message like that would have been given to alert you to the problem.

GW tasks (by design) are likely to take around 12 hours to complete on a relatively modern machine.  We could assume the elapsed time to crunch a task on your host (older Pentium dual core 2.5GHz) would be longer - say 18-24 hrs perhaps.  Even if slow, the task should be finished well within the deadline.  So the question I ask myself (and then try to answer) is, "how could such a task still be running and not finished 105 days after it was originally sent?"

Well, it probably depends largely on how you use your machine and how you have set your preferences.  If you turn the machine on, use it for a session and then turn it off when you finish, that could be a factor.  If you had a preference setting for suspending computation when the user is active set to 'yes', then it would be possible for very little progress to be made during the session.  User active just means the user was using the keyboard/mouse, irrespective of how much CPU activity there was.  So just processing emails or browsing the internet would prevent BOINC from doing work.  I notice your machine is running an old BOINC client and an old Linux kernel. I imagine it's not your 'daily driver' so perhaps it's putting itself into some sort of low power state and not actually doing any crunching until you 'wake it up'?

Another preference setting is for whether or not you allow tasks to remain in memory when suspended.  If that setting is to remove tasks from memory when suspended, then the only way for the task to continue when allowed, is to reload at the point where it was at the time the previous checkpoint was written.  So, with that setting, you always lose any computation after the last checkpoint up until the point where the task was suspended (and therefore removed from memory).

There's no need to click 'update' unless you have a specific reason to force contact with the project.  The client will take care of that automatically when needed.  The event log you posted was quite sufficient to show the situation.  I'd be interested in knowing how you managed to keep a task crunching for that long without it ever completing.  Information about your usage patterns and preference settings would be useful for diagnosing why the task wasn't completed within the original deadline.

From what you have said, you seem to be crunching only one task at a time, even though you have a dual core CPU.  Do you allow BOINC to use only 50% of the cores?  What size (in days) do you use for your work cache?

Hi Klaus,
Thanks for supplying the extra information.  I think it's now possible to explain the behaviour you have described.

Firstly, I believe your machine had been working on that one aborted Einstein task for three months and was never able to complete it - strange as that may seem.  This would explain why your client favoured the other projects and prevented a new Einstein task until just now. The client knew that it had spent many hours trying to complete just that one task so as soon as it was aborted and returned, the client had to favour other projects to give them their rightful share - as dictated by your resource share settings.  It took quite a while to 'catch up' the deficiency.

The real problem is caused by some settings that aren't appropriate for your main use of that machine.  You describe this as "it needs one core exclusive" for the "main job".  So by all means restrict BOINC to 50% of the cores if you wish.  However DON'T double restrict by setting "Pause on processor usage of 25%".

I've never tested this out but here is what I believe may very well be happening.  You need to understand that BOINC is designed to run at the lowest priority - it's designed to use 'spare' CPU cycles.  My experience is that it's quite good at this.  Of course that very much does depend on the characteristics of the main job.

A lot of 'heavy use' apps will tend to be 'bursty' - ie peaks of very high CPU use and troughs of very low use.  Unless the app is multi-threaded and extremely heavy in its CPU use, the 50% cores setting should give it all that it needs.  When you also set "Pause at 25%", I'm wondering if that is being interpreted as "any core using >25% for a non-BOINC app will cause a pause".  You really need to test this for yourself because I think that your main job probably has regular bursts above 25% and so BOINC dutifully pauses crunching when that happens, despite the main job having its own exclusive core to use.

Also, you don't have the setting checked for keeping the task in memory when suspended.  So that means if BOINC is being paused very regularly by >25% bursts on the other core, any progress is being thrown away and the task is forced to restart from the last saved checkpoint.  If your main job runs all the time the machine is on, I could then understand why that one task was never able to finish.

Another thought has occurred to me.  When you first posted about this issue, I seem to recall seeing a very old version of BOINC - version 5 or version 6 comes to mind (I could easily be mistaken).  Today I see version 7.2.42.  Have you upgraded BOINC recently?  If you have, I vaguely remember some sort of problem with very old BOINC versions to do with that "using >25%" setting.  I have a nagging feeling that when that was in use, old BOINC versions would pause crunching far more frequently than should have been the case.  I've never used that setting so I don't remember any details.  Whatever the issue was, I think it was fixed before 7.2.42 came along.  So if you have upgraded BOINC, you should be fine.

Your new Einstein task is not a GW task like the previous one.  It's a Gamma-ray pulsar task (FGRP5) and it will be able to finish a bit faster than a GW task (if you allow it to).  However it will checkpoint less frequently than the GW tasks so the potential to lose progress is higher if you don't change your settings as suggested.

As I write this, you've had the task for several hours.  I believe it should checkpoint on your machine, perhaps every 10-15 mins, or something like that.  It would be interesting to know how long the machine has been running since the task was received and what progress is showing for it (both elapsed time and % complete).  I believe it will write a checkpoint every 1.13924% of progress - ie. at values showing in BOINC Manager (advanced view) of 1.139%, 2.278%, 3.418%, 4.557%, ....  If you care to give the 3 figures at any point (machine on time, task elapsed time, and task % completed) it should be easy to see if significant crunching time and progress is being lost.  If you've already shut the machine off, just record the 3 values you see immediately after a restart and then again when you are about to shut it down.  The differences between the two sets will tell the story.

Yes, I did know what time it was in Germany so wasn't expecting an immediate reply.  As soon as I saw one, I guessed about the drinks as well :-) ;-).

Assuming the drinks were not excessive and your numbers are believable, :-)  I would say that everything is pretty much as it should be.  You received the task at 20:30 UTC 6 Jul and you posted at 01:10 UTC 7 Jul.  So, at the time you posted, the machine had been running the task for 4:40h which agrees very closely with the run time of 4:33h.  My conclusion is that you obviously need a few more drinks since you are not sufficiently inebriated - go look that one up :-).

Seriously, at the current rate of progress, the task will get to ~90% (the end of the primary calculations) at around an elapsed time of just over 11:30h.  The rate of progress for these tasks is fairly uniform so this number should be fairly close (unless you suddenly start losing progress due to restarting from an earlier checkpoint.  At ~90%, progress will seem to stop for perhaps another 30-50 minutes as the followup stage doesn't include an indication of continuing progress.  When the followup stage completes, the progress will jump immediately to 100% and the result will be uploaded.  Total time for the task should be between 12 and 13 hours.  This is very much what I would expect for your machine.

I don't know anything about recording/editing/post processing of video since I've never felt a need to do any of that.  I wouldn't have a clue as to what parts of the overall process consume a lot of CPU.  On the assumption that recording is just laying down the bytes on a disk, maybe the CPU isn't too stressed with this activity so the Einstein task isn't getting interrupted.

When you get your brain back :-) please see if you can work out what I've written and if it doesn't make any sense, please ask.  It will be interesting to know if this task fully completes in the projected time, or if something intervenes and it doesn't.  By the time you wake up - maybe afternoon local time :-) - it should be well and truly completed and hopefully replaced with something else.