Panic Mode On (76) Server Problems?

I accept that VLAR wu do take longer than `normal`
Though the longest i have seen one take on a 7970 is 25 minits (after i got it set up right)
I am willing to crunch nothing but VLAR if it was possible to do it.
Though i have not seen any heer since the latest problem was fixed.

As I type parts of the SSP are 206 hours behind. [As of 23 Aug 2012 | 8:30:04 UTC] SSP was behind before this weeks outage. How are the As of* times set?
____________

Live in NZ y not join Smile City?

A .vlar WU would mean x ~ 10.8 longer than a normal AR WU. Wasted performance.

bill - Can't agree. The vlar will take even longer to work on a cpu than a gpu.
To me crunching a work unit faster is better. If your gpu is not busy doing any other work units, why not let it do vlars if they cause no problems.

Sure, a GPU doing a VLAR might be better than an idle GPU (depending from your point of view), but if for a CPU it pretty much doesn't matter, if it's cruching a VLAR or a normal-AR task while the GPU is x times slower on VLAR, you are waisting performance if you send VLARs to a GPU. It's better for the project that a GPU do few 0.44 WUs instead of 1 VLAR. And it's up to the user to set his cache high enough that his card never idle (OK, not easy with the current load on servers, but that's another thing).

I teory thats ok, but when crunching the vlar with Nvidia GPU your entire system turn dificult to use, the cursor flicks, a lot of wierd problems start to apears with the video interface, so you almost loose the host for any other use until this WU is processed, so processing Vlars with NVidia GPU in a non dedicated crunchig host realy is a waste of resources. Lets the vlars running in the CPUS and all others on the GPUs.

From the project's point of view, they couldn't care less if the tasks run fast or slow.

Well, project like that would never get me to crunch for them. Such thinking from the project staff was a reason why I didn't join Milkyway earlier (those days when they had highly inefficent applications themselves, didn't except anonymous platform and all the other things they did back than). I want my resources to be used as efficently as possible by the project (hence I use opt apps), if I have more than my main project can use, there are other projects, who are happy to get what's over.

I think the thing to keep in mind here is that the batch of VLARs sent out to Nvidia GPU hosts was an unintended error, not a change in policy.

Several of my best rigs have been crippled in output by the VLARs that have risen to the top of their caches and are now being tackled by the GPUs, although very slowly. Watching my best rig struggle through 2 per GPU on very capable cards is painful to see...LOL.

But, the kitties have resigned themselves to letting the rigs work through it, and this too shall pass. I am not seeing any problems in the way of errors, just painfully slow processing.
____________
******

"Ask not, what your kitty can do for you. Ask what you can do for your kitty."

As it is kitten, so shall it be done.

I agree with you Mark, this was an unintended error and is fixed now.

For now... "Vlars to NVidia GPUs - Never Again"... unless someone find a way to bypass the problem with maybe some black magic... A task for our Master Guru Jason and his team...
____________

Please don´t missunderstud what I and Richard says, SETI is a project that is spected to runs DECADES before any spected success could be achived (unless of course our little green mens give us a hand), so "fast or slow" is relative to that, the difference from a 12 min WU (GPU) to a 1 1/2 hour (CPU) makes little difference to the 50 Years or maybe more project.

I wasn't talking about the progress of SETI@Home, as Richard pointed out we donate more resources to them than they can use ATM, I was talking about efficient usage of our resources by all projects and SETI is one, that can easily use nVidia GPUs more efficiently by not assigning VLAR tasks to them. The more the project care about efficient usage of our resources, the more science we get done, not necessarily for SETI (since they just can't send out more WUs than they are already doing now) but for other projects out there.

Please don´t missunderstud what I and Richard says, SETI is a project that is spected to runs DECADES before any spected success could be achived (unless of course our little green mens give us a hand), so "fast or slow" is relative to that, the difference from a 12 min WU (GPU) to a 1 1/2 hour (CPU) makes little difference to the 50 Years or maybe more project.

I wasn't talking about the progress of SETI@Home, as Richard pointed out we donate more resources to them than they can use ATM, I was talking about efficient usage of our resources by all projects and SETI is one, that can easily use nVidia GPUs more efficiently by not assigning VLAR tasks to them. The more the project care about efficient usage of our resources, the more science we get done, not necessarily for SETI (since they just can't send out more WUs than they are already doing now) but for other projects out there.

I don't think we're disagreeing here. Fortunately, not sending VLARs to NVidia is a win-win problem. The solution satisfies both the efficiency and the volunteer satisfaction criteria.

I was merely saying that, from the project's point of view, not alienating volunteers is the stronger argument. I don't think we'd have got the "don't send" solution coded in the first place, if we'd had to argue on the efficiency criterion alone.

I've been getting a lot of "No tasks sent" messages lately, and haven't been able to get any work for about an hour and a half.

I've been getting a lot of "No tasks sent" messages lately, and haven't been able to get any work for about an hour and a half.

23/08/2012 18:36:45 | SETI@home | [sched_op] Starting scheduler request
23/08/2012 18:36:45 | SETI@home | Sending scheduler request: To fetch work.
23/08/2012 18:36:45 | SETI@home | Reporting 1 completed tasks
23/08/2012 18:36:45 | SETI@home | Requesting new tasks for NVIDIA
23/08/2012 18:36:45 | SETI@home | [sched_op] CPU work request: 0.00 seconds; 0.00 devices
23/08/2012 18:36:45 | SETI@home | [sched_op] NVIDIA work request: 254142.76 seconds; 0.00 devices
23/08/2012 18:36:55 | SETI@home | Scheduler request completed: got 0 new tasks
23/08/2012 18:36:55 | SETI@home | [sched_op] Server version 701
23/08/2012 18:36:55 | SETI@home | No tasks sent
23/08/2012 18:36:55 | SETI@home | No tasks are available for AstroPulse v6
23/08/2012 18:36:55 | SETI@home | No tasks are available for the applications you have selected.
23/08/2012 18:36:55 | SETI@home | Tasks for CPU are available, but your preferences are set to not accept them
23/08/2012 18:36:55 | SETI@home | Project requested delay of 303 seconds
23/08/2012 18:36:55 | SETI@home | [sched_op] handle_scheduler_reply(): got ack for task 08au12ab.8651.6772.6.10.83_2
23/08/2012 18:36:55 | SETI@home | [sched_op] Deferring communication for 5 min 3 sec
23/08/2012 18:36:55 | SETI@home | [sched_op] Reason: requested by project