I don't know if you mean me.

My experiences showed, if BOINC ask for CPU and nVIDIA GPU WUs, BOINC get only GPU WUs until the WU cache is filled up.
So in this time BOINC get no .vlar WUs, because they are only for CPUs.

If the 'ghost/re-sent function' will send 'missed' WUs after BOINC asked for CPU and nVIDIA GPU WUs, BOINC get the 'Didn't resend lost task xxxxxxxxxxxxxxxxxxxxxxxxx.vlar_x (expired)' message if there were .vlar WUs and this WUs get a new deadline (finished).


- Best regards! - Sutaru Tsureku, team seti.international founder. - Optimize your PC for higher RAC. - SETI@home needs your help. -

---

On -> this page, there is an explanation of the "Time reported or Deadline" column in the tasks list...

Not reported yet, deadline in the past.
Deadline, shown in red.

...from which I take it to mean that when the date is red, then it is a deadline that has expired, which is what I was thinking originally.

---

I got one of these as well yesterday.

It was sent 31 May 2011 | 9:09:50 UTC
with a deadline of 31 May 2011 | 9:15:10 UTC


http://setiathome.berkeley.edu/result.php?resultid=1929727574

I got one of these as well yesterday.

It was sent 31 May 2011 | 9:09:50 UTC
with a deadline of 31 May 2011 | 9:15:10 UTC


http://setiathome.berkeley.edu/result.php?resultid=1929727574

...and again it is a VLAR.

I wonder if there is something more happening here with the VLAR WU.

---

...and again it is a VLAR.

I wonder if there is something more happening here with the VLAR WU.

Yes, and again - as we all told you yesterday (and please read back, if you're still not clear) - it is precisely part of the coping strategy for VLARs that causes us to to see this.

Back to first principles. SETI tasks are all the same. There is no such thing as a 'CPU task' or a 'GPU task'. BUT: experience told us that VLAR tasks run very, very slowly on GPUs (nVidia GPUs only, I mean, before any of the resident pedants chip in). The user desktop experience is also horrible when VLARs are running on a nV GPU.

So, a policy decision was taken that the servers wouldn't send a VLAR task to nVidia GPUs. That turned out to be easy to manage when tasks are first issued - you just don't see VLARs assigned to GPU crunching any more.

But when the communications are congested (as they have been recently), and messages between the servers and your computer are failing to battle their way through the cacophany, the question of 'lost results' comes up. And, once volunteer crunchers had contributed enough funds to purchase more powerful servers, the project was once more in a position to enable the code for "resend lost results". It turned out that VLARs were once more being sent out to GPUs.

The solution - admittedly, a bit of a kludge - was to fiddle with the deadline for VLAR tasks in danger of being sent to a GPU.

So, as Carola said, the sequence of events is:

• Your computer asks for CPU work (with or without a concurrent request for GPU work).
  
• The server assigns a VLAR for CPU processing, and sets a normal deadline (some 47 days ahead).
  
• The server sends a message to tell your computer about the work assignment.
  
• That message fails to reach your computer.
  
• Your computer still needs work, and five minutes later asks again - this time, with a request that includes work for a GPU.
  
• The server realises that the previous message didn't get through.
  
• It looks at the work which was previously assigned but lost, and tries to assign it again - starting by trying to fill the the GPU request.
  
• The server finds the VLAR task, previously assigned to the CPU, and realises that it can't be assigned to the GPU.
  
• The server changes the deadline of the task from "six weeks ahead" to "now" - "now" being the time of your second work request.
  
• It's now too late to do the work, so it doesn't get sent - the object of the exercise.
  
• The server moves on, and finds other work for your GPU.
  
• The left-behind VLAR task stays in the system, for assignation against another CPU request in due course.
  

It may not be elegant or intuitive, but that's how its done. And it works.

Thank you Richard for the consice explanation. When the servers had been jammed up before I have seen those timeouts and thought it was just a lack of communication. Now I know how they are caused. One less thing to fret over.

---

[/quote]

Old James

So, as Carola said, the sequence of events is:

• Your computer asks for CPU work (with or without a concurrent request for GPU work).
  
• The server assigns a VLAR for CPU processing, and sets a normal deadline (some 47 days ahead).
  
• The server sends a message to tell your computer about the work assignment.
  
• That message fails to reach your computer.
  
• Your computer still needs work, and five minutes later asks again - this time, with a request that includes work for a GPU.
  
• The server realises that the previous message didn't get through.
  
• It looks at the work which was previously assigned but lost, and tries to assign it again - starting by trying to fill the the GPU request.
  
• The server finds the VLAR task, previously assigned to the CPU, and realises that it can't be assigned to the GPU.
  
• The server changes the deadline of the task from "six weeks ahead" to "now" - "now" being the time of your second work request.
  
• It's now too late to do the work, so it doesn't get sent - the object of the exercise.
  
• The server moves on, and finds other work for your GPU.
  
• The left-behind VLAR task stays in the system, for assignation against another CPU request in due course.
  

It may not be elegant or intuitive, but that's how its done. And it works.

Thank you Richard for the consice explanation. When the servers had been jammed up before I have seen those timeouts and thought it was just a lack of communication. Now I know how they are caused. One less thing to fret over.

Yes, a concise explanation is what was needed.

As Ricky Ricardo would have said . . .
"Lucy! You've got some 'splainin to do."

---