Have a look on the Results Status page. What do you see?

Did you put the ????? into the RS print or are you now on a language set that does not render properly?

You are perfectly right to not want to show the actual device name, but you can suppress that at which time the RS pages will show the 5 or 6 digit Device ID which on one of mine is 628290

faah4326_ 001103_ MC_ xMut_ md01830_ 05_ 2-- 628290 Valid 08/27/2008 21:05:13 08/28/2008 09:51:23 2.94 45.3 / 49.6

A completely useless number but for me and WCG database.

Now, to the solution, plz post the BOINC msg log for any of these jobs completing and the subsequent transacting through when it bounces.

Just a few days ago I created a FAQ on network suspend and the vexing issue, but with us jointly reading the log, here, we can maybe lessing your I B KON FUZED.

TUVM

At the time of my previous post all the WU's lidentified as complete were 100 % complete and ready to report according to the clients "task" list view.

I did try to force a communications retry scenario and that produced no results. I attempted to change some of my queue depth values with no results; I tried to force a bench mark process which produced no results.

Now most ot the WU's in question have now been marked as valid in the web-page but I can't understand why it took so long for the status change.

Sekerob,

I'm trying to whittle the log down to something reasonable to post here... I need just a little more time to filter it... as it is, it appears to be to large to post.

So everything was going fine in fact:
Result files had been uploaded as soon as WUs complete (problems in this area are very rare) and the reporting actions were waiting for the scheduler to decide to request more work.
At this stage there is no normal direct action that you can do in BoincMgr to force such a request if you do not see anything abnormal in your message log. If you see that some previous request has been unsuccessful because of server problems or anything similar then you can try one (and only one) project Update from the Project tab to shorten the retry delay interval if you think the situation is back to normal.
If it has no effect do not insist with the Update button: the only result would be increasing the load of the servers and lengthening the delay before you can do another one.

Note that using the Update button should at least force the reporting of the "Ready to report" WUs, but as you know one should not do that too often for not stressing the servers exaggerately.

Back to requests for work, playing with the size of the waiting queue is the only indirect thing that you can do, but it has limits (10 days for WCG) and serious drawbacks: once you will have scores of WUs waiting you will have lost any flexibility in this area and you will increase your chances to miss deadlines if anything goes wrong.

At this point the only thing which you can do is to think about why is the scheduler not feeling the need for new work. Some of the following possible reasons are very obvious but I give them without any ironical flavor, only for trying to be as complete as possible.
1. you have reduced your extra work buffer parameter
2. running tasks are not progressing as fast as usual or as fast as you think
3. running tasks will need more time than anticipated (by you and/or the scheduler)
4. recently completed tasks have actually taken more time than anticipated and that has resulted in increasing (often dramatically) the estimated time of all waiting tasks (and also to some extent the time to completion of the running tasks)
5. there are tasks running "high priority" and interrupted tasks waiting to run; in that case, unless you are running with no queue or a very short one the scheduler will not request new work until these tasks have resumed.

In your case I would privilege options 3 and 4. You might see "high priority" tasks but with the high number of tasks ready to report I doubt that your waiting queue is small enough to be in case 5 really.

Personally I have always had concerns with the sizing of the FAAH WUs: WUs of very different sizes, underestimated WUs, etc... Every time I start selecting them my client is falling in case 4 above and the waiting queue becomes a real mess. That's why, usually, I don't select this project, knowing that there are so many members who privilege it that it is not a problem at WCG level. With the current FAAH draining in progress I have selected FAAH again in the two profiles I am using alternatively on my quad, and here I am, estimated times of very well calibrated HCC WUs have increased up to almost three times when I run Linux.

Under XP I have not had emergency FAAH WUs yet but I would expect the same phenomenon if/when I get some.

So what to do? Let Boinc do its job and sooner or later things will come back to a level where it will decide it is time to request new work, at last! And, in general, avoid large waiting queues which tend to magnify these undesirables effects. But I think you are more an adept of the very short queues normally.

One last side note since you mentioned it: the benchmarking process has no effect on those scheduling things, unless some Boinc guru disagrees. The scheduler is obviously impacted by the performance of your machine, but I am almost 100 % sure it is deriving it from real completed WUs and not from the benchmark figures.

Cheers. Jean.