As shown below, got total of 8 tasks even though none were asked for (according to the messages)

Sorry to say, but that's a useless log for the developers. Turn on the <work_fetch_debug>, <cpu_sched_debug> and <debt_debug> flags and try again. Then send the output thereof to the BOINC Alpha email list. Please follow these instructions if you want to Alpha test development versions. It's quite simple, really.

---

This isn't a CC problem, it's a backend problem.

It looks to me like SAH Beta and GPUGrid haven't gotten around to updating their software package yet.

<edit> @ Ageless: Note the proper behaviour for Cosmo.

Alinator

I know that and have said something like that before to BeemerBiker, but he still wants to Alpha test and report it here.

---

This email exchange took place on the BOINC Development mailing list on 30 January.

From: "David Anderson"
To: "Richard Haselgrove"
Cc: "BOINC Developers Mailing List" <boinc_dev@ssl.berkeley.edu>
Sent: Friday, January 30, 2009 12:13 AM
Subject: Re: [boinc_dev] Scheduler Request Calculation

This may be fixed now (beta had an old scheduler)
-- David

Richard Haselgrove wrote:
> There is an added complication at SETI Beta in that the SERVER is sending
> out work even when the client doesn't request it.
>
> http://setiweb.ssl.berkeley.edu/beta/forum_thread.php?id=1524#36670

David often does the SETI server updates himself (he has a dual role as Director of SETI, as well as lead developer for BOINC - see About SETI).

BB's screen-shot suggests that the problem, identified prior to 30 January, has not been cured by whatever upgrade David applied. Which client-side logs (reportable by project participants) would help the BOINC developers track down this server bug?

As shown below, got total of 8 tasks even though none were asked for (according to the messages)

Disagreed. NNT is working now, at least with Win2003, BM 6.6.5, non-service installation.

Both projects (S@H main and beta) had been set to NNT and update button was pressed.
Here is my log.

11-Feb-2009 15:41:59 [SETI@home Beta Test] [sched_op_debug] Starting scheduler request
11-Feb-2009 15:41:59 [SETI@home Beta Test] Sending scheduler request: Requested by user.
11-Feb-2009 15:41:59 [SETI@home Beta Test] Reporting 1 completed tasks, not requesting new tasks
11-Feb-2009 15:41:59 [SETI@home Beta Test] CPU work request: 0.00 seconds; 0 idle CPUs
11-Feb-2009 15:41:59 [SETI@home Beta Test] CUDA work request: 0.00 seconds; 0 idle GPUs
11-Feb-2009 15:42:09 [SETI@home Beta Test] Scheduler request completed: got 0 new tasks
11-Feb-2009 15:42:09 [SETI@home Beta Test] [sched_op_debug] Server version 607
11-Feb-2009 15:42:09 [SETI@home Beta Test] Project requested delay of 7.000000 seconds
11-Feb-2009 15:42:09 [---] [sched_op_debug] handle_scheduler_reply(): got ack for result 03no08aa.3988.4162.15.11.58_1
11-Feb-2009 15:42:09 [SETI@home Beta Test] [sched_op_debug] Deferring communication for 7 sec
11-Feb-2009 15:42:09 [SETI@home Beta Test] [sched_op_debug] Reason: requested by project
11-Feb-2009 15:42:14 [SETI@home] [sched_op_debug] Starting scheduler request
11-Feb-2009 15:42:14 [SETI@home] Sending scheduler request: Requested by user.
11-Feb-2009 15:42:14 [SETI@home] Not reporting or requesting tasks
11-Feb-2009 15:42:14 [SETI@home] CPU work request: 0.00 seconds; 0 idle CPUs
11-Feb-2009 15:42:14 [SETI@home] CUDA work request: 0.00 seconds; 0 idle GPUs
11-Feb-2009 15:42:20 [SETI@home] Scheduler request completed: got 0 new tasks
11-Feb-2009 15:42:20 [SETI@home] [sched_op_debug] Server version 607
11-Feb-2009 15:42:20 [SETI@home] Project requested delay of 11.000000 seconds
11-Feb-2009 15:42:20 [SETI@home] [sched_op_debug] Deferring communication for 11 sec
11-Feb-2009 15:42:20 [SETI@home] [sched_op_debug] Reason: requested by project

As You can see, no new workunits had been downloaded.

Unfortunately, it doesn't seem to be as simple as that. Both you and BB were "not requesting new tasks". You didn't get any, as is correct: BB got 2 new tasks anyway.

That isn't a NNT problem, it's a server problem. It happens very rarely, which makes it very difficult to isolate and fix (if everyone was getting work they hadn't asked for, all day every day, I think it would have been solved by now!)

All we can say to David Anderson is (a) the problem isn't solved yet: it still happens, though rarely, and (b) we haven't come up with any ideas yet about what we, as client operators, can supply by way of evidence to help him track it down.

All I can suggest is that anyone who actually spots it happening should disable network activity (to prevent files being over-written) and take a copy of the sched_request_ and sched_reply_ XML files for the project.

Chicken Little says 6.6.5 may be working after all

I ran another update with NO-NEW-WORK set and this time got no data. The only thing I can think of is that the WU results that were sent out when I ran the "user update" yesterday had all been prepared by 6.6.4.

This time, all the results going out to the servers had been prepared by 6.6.5 and this is what the log showed(i ran update twice and go the same results as follows):



I will try this on my other system that still has a mix of 664 and 665 results.

and (b) we haven't come up with any ideas yet about what we, as client operators, can supply by way of evidence to help him track it down.

See my earlier post which requests which flags to turn on.

---

and (b) we haven't come up with any ideas yet about what we, as client operators, can supply by way of evidence to help him track it down.

See my earlier post which requests which flags to turn on.

Yes, I saw that one, but surely <work_fetch_debug>, <cpu_sched_debug> and <debt_debug> collectively can only reveal the decision-making process by which the local client came to its conclusion: "not requesting new tasks".

The server shouldn't, AFAIK, be responding to that reasoning: it should only be responding to the actual sched_request...xml. Or are you suggesting, in light of Dj Ninja's "bug or feature?" thread on the mailing list, that the server is in effect saying "hehe - I've checked your calculations on the list of all the work you've got on hand, and you got it wrong: you didn't ask for any work, but you should have done, so I'm sending some to you anyway - so there".

Still, it never hinders the investigation process to have additional information on hand, and possibly having those flags turned on will reveal something relevant. Of course, the one logging tool that would really help our understanding here would be the server log: if the problem was being reported at Einstein, we could click through from the host record to the relevant server scheduler log for the host: but that isn't available at SETI Beta, and I'm not going to email Eric and ask for it while he's in the middle of an application launch.

Set <sched_op_debug> on, it'll tell you what the scheduler deemed was needed.

---

In 5 hours run out of work again. :( Then the scheduler ask for cuda work from every projct but not from Gpugrid.

Please tell me what the scheduler 6.6.5 need:

17.02.2009 01:40:18 GPUGRID [sched_op_debug] Starting scheduler request
17.02.2009 01:40:18 GPUGRID Sending scheduler request: Requested by user.
17.02.2009 01:40:18 GPUGRID Not reporting or requesting tasks
17.02.2009 01:40:18 GPUGRID CPU work request: 0.00 seconds; 0 idle CPUs
17.02.2009 01:40:18 GPUGRID CUDA work request: 0.00 seconds; 0 idle GPUs
17.02.2009 01:40:23 GPUGRID Scheduler request completed: got 0 new tasks
17.02.2009 01:40:23 GPUGRID [sched_op_debug] Server version 607
17.02.2009 01:40:23 GPUGRID Project requested delay of 31.000000 seconds
17.02.2009 01:40:23 GPUGRID [sched_op_debug] Deferring communication for 31 sec
17.02.2009 01:40:23 GPUGRID [sched_op_debug] Reason: requested by project

---

Steter Tropfen höhlt den Stein. :)
Constant dripping wears away the stone. :)