EDIT: Hmm, tasks are running 6-8h before hitting the limit, so that shouldn't be it. Did you reboot? I don't see a driver change on either computer from working to not. 388.59 and 388.13 I think they were. Maybe driver reload time ...

Have you been having any video driver crashes on those machines? I have one machine that gets those quite frequently. The driver recovers, but the side effect is that GPU tasks that are running when the driver crashes sometimes seem to hang, though not always. The elapsed time increases but the progress does not. The only way I manage to avoid getting the timeouts that you're experiencing is to check on that machine a couple times a day to see if any tasks are hung. If they are, I just suspend those individual tasks briefly, then resume. When they start running again, the elapsed time drops back to a more normal figure and everything runs along just fine (unless there's another driver crash).

Interestingly, I never used to have that problem when I was running a 550Ti in that machine. It only started when I switched to a 750Ti a year or so ago, and continues today with a 960. At the time I installed the 750Ti, I was running Cuda, so the first thing I did when the driver crashes started was to switch to SoG. No change. After that, I tried newer drivers, older drivers, TDR delay increases, etc., etc., with no discernible effect, so I've just learned to live with it. I generally manage to avoid the errors, but I often end up with several hours of lost processing time before I discover that a task is hung.

On my Win 10 systems, i'm running 372.54 without issues.
I can't remember if I had to do the TDR registry edit or not- I did have to do it on my C2D with 32bit Vista to stop driver re-starts (and I had to stick with a much older driver version otherwise I would get restarts even running CUDA50). Basically it just increases the period of time before the OS thinks the video driver isn't responding & re-initializes it. You can disable this function, but it means a full system crash if you have a driver problem actually occur.Graphics driver stopped responding and has recovered....TDR fix (see solution 3).
I think you might be running in to similar issues I had- 32bit OS, low CPU clock speed results in (relatively) long delays in handling system interrupts & the TDR kicks in.

For me, even bumping the TdrDelay all the way up to 16 (0x00000010) didn't help, or at least didn't help much. I just figure that once I moved from the 550Ti to the 750Ti, the speed and efficiency of the newer GPU just became too much for the old C2D and/or the MB bus to handle consistently. I just looked at that system and found that it's had 3 driver crashes in the last 17+ hours, though none of them caused any tasks to hang. I've never tried to figure out if there's a pattern of any kind. It just didn't seem to be worth the effort.

For me, even bumping the TdrDelay all the way up to 16 (0x00000010) didn't help, or at least didn't help much. I just figure that once I moved from the 550Ti to the 750Ti, the speed and efficiency of the newer GPU just became too much for the old C2D and/or the MB bus to handle consistently. I just looked at that system and found that it's had 3 driver crashes in the last 17+ hours, though none of them caused any tasks to hang. I've never tried to figure out if there's a pattern of any kind. It just didn't seem to be worth the effort.

32bit OS?
I'd always thought of putting a C2Quad in mine thinking that would help (I've got 2 GTX 750Tis in there), but it's looking like it boils down to the 32bit OS, and the slow clock speed. A 64bit OS would probably allow the system to use more of the RAM, with less resource contention with the larger available address space.
On mine, the harder the GPUs work, the less time the CPU has to process WUs, and the higher the system resources taken up with Interrupts & DPCs (up to 15% when I tried to run SoG on it).Grant
Darwin NT

32bit OS?
I'd always thought of putting a C2Quad in mine thinking that would help (I've got 2 GTX 750Tis in there), but it's looking like it boils down to the 32bit OS, and the slow clock speed. A 64bit OS would probably allow the system to use more of the RAM, with less resource contention with the larger available address space.
On mine, the harder the GPUs work, the less time the CPU has to process WUs, and the higher the system resources taken up with Interrupts & DPCs (up to 15% when I tried to run SoG on it).

Yeah, 32-bit Vista on an old HP dc7700 with a C2D E7500. I did switch over to SoG (from Cuda50) to see if that would help, but there really wasn't any discernible change in the driver crashes or task hangs. I stuck with SoG, though, because I still get better overall production out of it. It can sometimes go several days without any hangs, then get a couple in the same day. Just no obvious pattern. That machine is mainly a crunch-only box. Once in a great while I use it for streaming (through an HDMI connection to my plasma TV), but on those occasions I shut down BOINC first.

32-bit Vista on an old HP dc7700 with a C2D E7500. I did switch over to SoG (from Cuda50) to see if that would help, but there really wasn't any discernible change in the driver crashes or task hangs. I stuck with SoG, though, because I still get better overall production out of it.

On my 32bit Vista system i'm running 344.11 Anything higher and even with CUDA50 I got driver restarts. I even tried just 1 GTX 750Ti, reserved a core for it and just used the defaults for SoG, but still got too many driver restarts.
With CUDA50 i'm running 2 WUs at a time (although it makes the Arecibo WUs take 3 times as long if run with a GBT WU), but at least there are no restarts. I've lost entire caches to restarts.
:-/Grant
Darwin NT

On my 32bit Vista system i'm running 344.11 Anything higher and even with CUDA50 I got driver restarts. I even tried just 1 GTX 750Ti, reserved a core for it and just used the defaults for SoG, but still got too many driver restarts.
With CUDA50 i'm running 2 WUs at a time (although it makes the Arecibo WUs take 3 times as long if run with a GBT WU), but at least there are no restarts. I've lost entire caches to restarts.
:-/

I'm running the 353.62 driver, which I think is as low as I can go with SoG. I'm pretty sure that's about what I was running with Cuda50, also, but I don't remember if I tried to go lower or not. Probably not.

Bernie Vine wrote:

So as both machines are getting a bit long in the tooth now I think I will let them retire gracefully.

Maybe it would be a good time to try experimenting with Linux. Since I've been running Linux on 3 of my other boxes, I've also considered switching over my problem child but, since I'd want to keep the Windows partition to make it dual-boot, I'd have to put a larger HD in it first. Just not enough room on the current drive for another 30GB partition.

But also a gaussian score being returned here, so except for that of a graphics card which could be used, apparently something "hogging" the CPU here,
and if so, I would always choose to pull the floppy drive when it is happening.

Well this morning both machines had stuck tasks. So I suspended then un-suspended and what then happens is that it pauses for a minute, then the task that was hung goes into "waiting to run" and a new task starts.

On both machines I have set NNT and one has now reached its last GPU task one that has been "waiting to run" what then happens is this

As to Linux, I have to admit i have tried it in the past, but I am to "Windows" orientated. I admit if it cant be done with a GUI then I am not interested. Looking at some of the Linux threads in NC and I see I would again get frustrated and give up one more.

I do have 3 other old machines currently doing nothing and I will fire one of them up see if I can get it running then perhaps put one of the 750's in it to see if the problem persists.

P.S

I would always choose to pull the floppy drive when it is happening.

Er I assume you mean DVD drive, these machines may be old but as they are Dell's they don't have "floppy drives". ;-)

Did you try to increase the windows swap file? Or use a less aggressive SoG setting for memory usage?

Ask because some (me included) has several problems few weeks ago after some windows updates related to the available memory.
Yes i agree, that sounds weird but changes in the memory setting fixes the problem.

Not say this could be your problem since the msg we receive was task postponed not Waiting to acquire lock but our GPU was 1060/1070 and yours is a 750. You lose nothing if you check that.

Perhaps right there, Bernie, but also that a DVD should still be having a driver interfacing against the operating system,
and my guess is that stuck drivers should not affect the CPU itself, because this should rather be the responsibility of the operating system.

Therefore perhaps making it the needle rather than the soft pillow here, because except for that of speed, always that of a couple of questions around for
that of running tasks by means of a graphics card.

Here the opposite thing, however, so therefore I gave it the regular look in the usual way of looking at that of possible hardware which could be affecting the CPU,
and from own experience, should tell that a stuck floppy could bring a whole system to a halt.

Not for that of an election here, since I made a similar reference to that of Deadlock earlier on, except for perhaps not an external event being the possible reason,
but rather an internal one being part of the current scheme.

Becomes a mentioning to that of I/O here (or input/output), but rather I was thinking about that of IRQ here being perhaps a more common or typical thing.