Discussion Thread for the Continuous GW Search known as O2MD1 (now O2MDF - GPUs only)

Watching GW GPU tasks on my BOINC manager I see a curious thing. Progress rises very rapidly up about 14% in about 3 minutes, then falls back to 0.470 and rises more slowly.

Tullio

I don't know how you don't understand this.

it has nothing to do with your wingmen or youtube or windows updates or whatever other nonsense you are trying to distract with. the GPU is insufficient for certain GW tasks, and there is nothing you can do to prevent from getting them except stopping GPU GW processing.

some tasks will run OK. some tasks will not. some tasks require less than 2GB of GPU memory, these will succeed. some tasks require more than 3GB of GPU memory. these are the ones that will fail. they come in random and unpredictable times. the reason you haven't seen failures today yet is simply because you haven't been sent the large tasks in a little while. that doesn't mean the issue is fixed. you WILL receive the large tasks again and you will produce errors again.

please do everyone a favor and just stop GW processing on that 3GB GPU. you are just making the already bad situation worse.

Preliminary results with an Amd Radeon 5700 on GW gpu indicate almost not change in processing speeds from 1 task to 3 tasks.

It runs from 18+ minutes to under 21 minutes.  So basically an R5700 can out produce high-end Nvidia cards if you run 3 gpu tasks.

There may be memory issues with 3 gpu tasks just like there is with a Gtx 1060 3GB video card.

I am switching my Pulsar Search#1 box to run both P and GW gpus since I expect the R5700 to  end up on it possibly by the weekend.

Tom M

What you should be doing is hitting the developers with a clue stick so that large tasks are not sent to people with small cards.

hard to say. when I was testing out my 1060 3GB to see the failure mode, what happened was the card started loading data into GPU memory, and filled up in the first 10-15 seconds or so, at that point, the task progress jumped from 0 to 100% and moved to "complete", but kept trying to reload the data into the GPU memory over and over and wouldn't start a new task. I watched the GPU mem climb to full then crash to 0, and over and over and over. it sat there for quite a while with this behavior (several minutes) until I manually aborted it. but the reported run time only logged 15 seconds or so, when in reality it had really wasted minutes and minutes (and only that because I intervened) of the PCs time. It's probably the similar for others. so you can't use the runtime to accurately gauge how much time it wasted on the the afflicted hosts.

I think if you are aware that your system is producing errors and bad results for a project, and you know the reason, and you know how to fix it, you have the obligation to do so for the benefit of the project. not just let it keep pumping out errors because "some" are still succeeding. this same mindset plagued several projects where bad AMD drivers caused consistently incorrect computations on RX5700 (navi) cards, which validated with each other, but invalidated against everyone else. or when Nvidia changed something in their ~436 Windows drivers that only affected one type of WU at SETI. several people thought they would just leave their system generating tons of bad results choosing to ignore the bad results and only look at the ones that validated without understanding what was happening.