holy cow! 20 timeouts

Last time I checked the ghost task VLAR timeout was more opposite of your description.

1) Host requests work for CPU or CPU & GPU.
2) Server assigns VLAR tasks to the CPU, but the host doesn't receive the list.
3) Host requests work for just GPU.
4) Server wants to send the tasks the host doesn't have.
5) The check for not allowing VLAR tasks on the GPU is tripped.
6) The tasks are marked as "Timed out - no response".

I think there was some talk about trying to prevent this, but I don't know if that was just talk or not.

IIRC: When a host makes a request it sends its list of all tasks in the client_state.xml. So if they are being processes, waiting, or in a transfer state it will tell the server "Hey I have these tasks".


____________
SETI@home classic workunits: 93,865 CPU time: 863,447 hours

Join the BP6/VP6 User Group today!

It's more likely to be the other way round. Your computer asks for CPU tasks, and is assigned VLAR workunits (somebody was saying yesterday that there were a lot around at the moment).

If that message gets lost, and the next request is for GPU work, that's when the deadlines get fudged (because of the "don't send VLAR to nVidia" rule).

Apart from the 'no VLAR to NV' situation, there's nothing (except possibly your preferences) to stop a "lost" result being issued to a different computing resource the second time round - when VLARs were being issued to GPUs because of a bug recently, I published instructions for a technique of deliberately losing them and getting them resent to CPU instead. That's the situation you suggest might cause problems, but it worked well for those who tried it.

As regards the client telling the server about work it knows has been allocated, but not yet downloaded - I don't know. I'll take a look next time I have some downloads stuck. Murphy has decreed that I'm all green, just at the moment...

Edit - got some. Yes, confirming Hal's post - allocated but not yet downloaded do get reported to the server.

Check out all my timeouts. I've never experienced this before. Can someone explain to me what might be causing this all of the sudden, and what steps I can take to prevent it from happening in the future?

Look at all those VLARs, as previously discussed.

I don't understand any of that jargon. Riddle me this simply: Is it something that I did or that shows that there is something wrong with my computer that I can fix/change?

Yep, I have a sharp increase in errors due to VLARs misdirected to GPUs as well.

Somewhat-related question: With the recent changes to the scheduler, are VLARs no longer sent to ATI GPUs now? I'm certainly not complaining - while VLARs don't suffer with ATI GPUs nearly as badly as NV GPUs, I do often get a drop in the responsiveness of the OS GUI. I just haven't noticed any VLARs assigned to the ATI GPUs over the past several weeks and I'm enjoying this change, if it was indeed a deliberate change in the scheduler code.
____________
Soli Deo Gloria

Somewhat-related question: With the recent changes to the scheduler, are VLARs no longer sent to ATI GPUs now? I'm certainly not complaining - while VLARs don't suffer with ATI GPUs nearly as badly as NV GPUs, I do often get a drop in the responsiveness of the OS GUI. I just haven't noticed any VLARs assigned to the ATI GPUs over the past several weeks and I'm enjoying this change, if it was indeed a deliberate change in the scheduler code.

I'm also getting a bunch of timeouts last few days....

if the host asked for GPU and (as far as it knows) didn't get any, why wouldn't it ask for GPU again the next time?

As said before, it asks for CPU tasks, they are lost and then, at least 5 mins before, they asks again for more tasks...
Well, in those 5 mins it may happen that the GPU Cache reach the "request more work" trigger so it asks for CPU and GPU, as the scheduller will try to fill first the GPU cache it will try to assign the losts tasks (originally intended for the CPU) to the GPU...

Ah hah. That was the answer I was looking for (instead of just correcting me on the details). I forgot that on a dual request, it tries to fill GPU first.

There are something else, if you are also attached to other projects, after the request fails to receive the needed CPU tasks, it migh ask for CPU tasks to another project while waiting for the 5 min delay, and if it gets tasks then it may not need CPU tasks anymore.

And I didn't think of that. Although in my case, I have only one other project, Einstein, and all of my computers have been shying away from it lately (one of the three has a couple of tasks due in three days and the others haven't contacted it since they reported their last ones about a week ago).

As to the list including undownloaded tasks, thanks to the guys who answered. It was just an idea.

BTW, I'm up to 53 timeouts now.