Stalled task at 89.989 % and another at 89.980 %

I gave some background on what I was doing and why. I am suggesting that the problem might come far earlier in the the WU processing than 89%. I think it is only getting to 89% because of the long run time.  If this comment is a problem, feel free to delete it. I won't be offended.

I turned both machines off and moved the 2080ti board to the Linux machine. The Linux machine detected the 2080ti, but did not complete and report any completions or failures. I let the GPU WU run on the 2080ti for an hour.  I started an Einstein GPU WU from its beginning and progress percentage increased slowly. The 1080ti board takes 7 minutes to complete and uniformly crunches the job.  I was expecting the 2080ti to take half that long, if it worked.

Sorry, I neglected to check the checkpoints.

Thanks for starting the new thread.  I see Richard has responded there and has suggested that you bring yourself up to date with the comments of quite a few people who have already been affected by this problem.  Archae86 has also responded to your report here and linked to the big Turing thread where he first reported the problem with a particular type of GPU task using a new Turing series GPU.  That was back on 30th Sept last year and would be a suitable starting point in becoming familiar with what is known about the problem.

There is a lot of reading if you want to know the full story so far.  The one sentence summary is that everything conceivable has been tried and there is currently no resolution, or even any real indication of where the true cause of the problem lies.  There have been multiple reports to nVidia about it.  There has been no comment about it from the Einstein Devs.  This suggests that they are just as baffled about the cause as everyone else.  If it was an easily fixable app flaw, the fix would have been made very promptly. As the problem has continued for several months, the indications point to something much harder to solve, and possibly only solvable by nVidia.

Just like you did, Keith Myers also tried running the card under linux.  This was back on Dec 6th.  He let a task run for a total of about 9 hours with no real progress being made.  He also observed the BOINC 'simulated progress' that you see when there is no checkpoint created from which 'true' progress could be calculated.  The progress you saw was obviously this same effect.  Richard calls this 'pseudo-progress', I believe.  Apparently some projects don't checkpoint very frequently so it's supposedly of benefit in stopping inexperienced people from thinking a task has stalled prior to the first checkpoint.  If real progress is being made, Einstein GPU tasks will checkpoint after the first minute.  The easiest way to confirm this is to check the task properties a little after that.  If there is still no checkpoint, then the task is apparently not running, no matter what the pseudo-progress indicates.

There have been other reports as well - from Windows users.  This thread contains several.  As far as I'm aware, people have been reporting the problem to nVidia for quite some time now.  I don't know of any meaningful response.

Hi, welcome to the forums.

Do you have the preference to suspend BOINC stuff when you use your computer set to 'Yes'?  If so, do you have the setting to keep tasks in memory when suspended also set to 'Yes'?

If you don't keep tasks in memory when suspended, each time one tries to restart after being suspended, it will need to read the last saved checkpoint from disk.  If checkpoints are widely spaced (it does vary with different tasks) you can lose a lot of compute progress as you do your ordinary work on your computer.

Before suggesting anything else, please rule out this setting as the possible cause of the issue.

OK. I didn't check the precise format of the prefs - some are y/n and some are tick boxes.  I figured you'd work it out :-).

So, if you don't suspend BOINC when you're using, does your machine put itself into some sort of low power state when you're not using it?  There's got to be some reason for long periods of no progress.  In any case, I'd recommend allowing tasks to stay in memory if they do happen to become suspended.  This will cut out the potential for significant loss of progress that can otherwise occur.

This will have no effect if the checkpoint interval specified by the app itself is longer than that, which most certainly it will be - perhaps a lot longer with some tasks.  You can check this for a running task by looking at its properties in BOINC Manager and noting the CPU time since the last checkpoint and then noting when that value gets reset immediately after a new checkpoint has been written.  It's less convenient with current BOINC versions than it used to be unfortunately.

You haven't mentioned what type of Mac you are using but from what is listed on the website, it would appear to be a laptop of some type.  That seems to suggest that it's saving power by not allowing BOINC stuff to run for a lot of the time.

You have two returned tasks showing on the website.  If you click the Task ID link for each task you can get a complete crunching record that was returned to the project.  Scroll down below the "Stderr Output" heading.  The "Sky points" value shown for each tells you how many checkpoints there were in the task.  The "nf1dots" parameter tells you how many 'calculation loops' there are for each sky point.

For one task there were 6 sky points and 689 nf1dots.  For the other the values were 60 and 74 respectively.  With only 6 sky points, the checkpoint interval will be very long and therefore lots of opportunity to 'lose' significant progress if calculations need to keep restarting from the previous checkpoint.

The total 'calculation loops' is the product of the two numbers so the task with the 6 sky points and 689 nf1dots actually had a slightly lower total number.  In theory, it could have finished a little faster than the other one if there wasn't all the lost crunching.

Each time an individual 'calculation loop' is completed a 'dot' is written to the output - hence the rows of 'dots' that you can see.  When a sky point is completed, a checkpoint is written.  The short line that starts with a "% C" shows when that happens.  The digit following the "C" is the checkpoint number.  If you see partial groups of dots without the short checkpoint indicator following them, that represents lost crunching.

It's worthwhile looking through the stuff returned to the project like this.  It can help diagnose the behaviour you are seeing.