I do not understand the distinction you make between uploading results and reporting results. I just lost 42 results that had been uploaded but not reported. Why do you not report at the same time the results are uploaded?

---

<a href="http://boinc-doc.net/boinc-wiki/index.php?title=Template:Definition:_Reporting_Process">Read this</a>.

---

I know this may not completely answer your question, but look at the process explained in the Wiki.

In essence it's two different servers that you are contacting. One is the upload to the database server, to return your data. Two is the reporting to the scheduling server. With this you will then also download new work.

---

Just because it is a two stage process does not mean that it can not be done immediately. Just as you have an upload result immediately setting you can have a report result immediately setting. The report can be dependent on the the success of the upload. I do not know if the uploaded but unreported results are any good to the project or not, but it seems they are lost. If the results are lost on the client machine for some reason before they are reported it seems that those work units will remain marked as uncompleted until they pass the report deadline and get reissued, re-computed and hopefully successfully reported this time. That to me seems like a design flaw. Anyway, I lost 42 work units and now the other users who had those work units will have to wait until they get redone in order to get their credit.

---

I'm just asking for clarification here. I'm not sure exactly what you mean by you "lost 42 WUs". How do you know they are lost? At what point did they get lost?

---

Jim,
I am working the PredictorAtHome project. My computer had worked on work units for 24 hours, it usually does a work unit every half hour. I tried to upgrade the Boinc core client this morning before I had done a manual report completed work units. Things went wrong with the upgrade and all the work unit in the queue, completed and uncompleted were elimninated and new ones downloaded when I got everything corrected. I don't know they are lost, they are in Predictor's database afterall, I just know I have not received any credit, between 180 and 220 credits usually for a days work.

---

I am working the PredictorAtHome project.
&lt;snip&gt;
... I don't know they are lost ...

Perhaps someone over at P@H can assist you with this. They would need some more details from you though.

I tried to upgrade the Boinc core client ... Things went wrong with the upgrade ...

Did you eventually succeed with the upgrade?
From what you've described so far, I'd suspect that you were going from a pre 4.4x client. You'd have needed to uninstall the earlier client first. Work isn't typically lost when uninstalling, and it's the most reliable form of moving between versions.

For what it's worth, the current recommended version (4.45) has a different scheduler logic code to the older client that will usually report each result immediately after it has uploaded. If communication to the project has been delayed (a red "Deferring communication with project for" XYZ time period in the messages list will alert you), then results will be reported at the next communication interval, or when a manual update is performed on the project.

Perhaps too late to fix your recent problem, but it should answer your original question and hopefully save you in future.

Kind Regards

---

ralic's law of forums: Irrespective of any prior research done, you will find the solution to your question shortly after posting it to a public Internet forum, resulting in readers concluding that you have done no research on the matter whatsoever.

Chris,

Yes, I eventually succeeded with the upgrade, just to take it out and go back to what I had before. It actually wasn't an upgrade. I have compiled and run the Linux version of Boinc-4.72. Debian now maintains the latest versions for the AMD64 architecture and I was attempting to switch to that so that I would no longer need to keep track of the latest version and build it myself. I could just use synaptic. Well that did not work because the Debian project leaves the architecture setting as something like "x86_64-unknown-linux-gnu" and the Predictor project does not recognise that as a valid architecture and will not send you units. I have to change a config setting before I build so that it reports my machine as a "i686-pc-linux-gnu", even thought it is not, so that they will send me work.

I have set the run options so that when a work unit is completed it is uploaded immediately. It will not report immediately however. I usually do that manually every morning. And that is my complaint. We should be able to have them automatically reported more often than is done now. About once every two or three days on this machine. Well I figured out how to do that. Using the boinc_cmd or boinccmd programs I can setup a cron job to do an update whenever I want, say every half hour on this machine, once an hour on my Wife's machine, and once every four and a half hours on the server. The downside of that is I won't be able to see the completed work units before they are reported, but it beats losing them. And work unit get reported closer to when they are completed so your daily stats should be more in line with what I am really doing.

---

It will not report immediately however. I usually do that manually every morning. And that is my complaint. We should be able to have them automatically reported more often than is done now.

AFAIK, the scheduler is automatically triggered to report after every successful upload, unless communication is deferred, or network activity is suspended (moot, because it also wouldn't be able to upload), or you've encountered a bug.

Since 4.72 is a dev build and you could be experiencing a bug, is there any particular reason that you haven't built the 4.45a release tag from source?

[edit]

For example, consider the following messages lines. I know the project isn't the same, but the principle is sound.

02/09/2005 18:05:49|SETI@home|Finished upload of 09dc03aa.21990.6994.142324.125_2_0
02/09/2005 18:05:52|SETI@home|Sending scheduler request to http://setiboinc.ssl.berkeley.edu/sah_cgi/cgi
02/09/2005 18:05:52|SETI@home|Requesting 0 seconds of work, returning 1 results
02/09/2005 18:06:06|SETI@home|Scheduler request to http://setiboinc.ssl.berkeley.edu/sah_cgi/cgi succeeded

02/09/2005 18:06:07|SETI@home|Finished upload of 09dc03aa.21990.6994.142324.131_1_0
02/09/2005 18:06:10|SETI@home|Sending scheduler request to http://setiboinc.ssl.berkeley.edu/sah_cgi/cgi
02/09/2005 18:06:10|SETI@home|Requesting 0 seconds of work, returning 1 results
02/09/2005 18:06:32|SETI@home|Scheduler request to http://setiboinc.ssl.berkeley.edu/sah_cgi/cgi failed

The scheduler request to report the result is sent some 3 seconds after completing the upload.
[/edit]

---

ralic's law of forums: Irrespective of any prior research done, you will find the solution to your question shortly after posting it to a public Internet forum, resulting in readers concluding that you have done no research on the matter whatsoever.

AFAIK, the scheduler is automatically triggered to report after every successful upload, unless communication is deferred, or network activity is suspended (moot, because it also wouldn't be able to upload), or you've encountered a bug.

Since 4.72 is a dev build and you could be experiencing a bug, is there any particular reason that you haven't built the 4.45a release tag from source?

I have run 4.19, 4.30, 4.32, 4.35, 4.43, 4.66, 4.68, 4.71 and now 4.72. I have never seen the work results reported immediately after uploading them in any of these versions. That may be because I have always used a large queue, 10 days actually. In the early days with Predictor if I set my queue to 1,2, 3, or even 4 days it would run out of work with in a day and not get any more until the next day. I would have to update manually or my machine would sit idle. Predictor has a 7 day deadline on work units, but they allow you a queue length of 10 days. Even though I use 10 days for my gueue lenght, it seldom takes more than 3 or 4 days to process everything the queue. If I don't manually update every day, it will automatically update every 2 or three days.

For example, consider the following messages lines. I know the project isn't the same, but the principle is sound.

02/09/2005 18:05:49|SETI@home|Finished upload of 09dc03aa.21990.6994.142324.125_2_0
02/09/2005 18:05:52|SETI@home|Sending scheduler request to http://setiboinc.ssl.berkeley.edu/sah_cgi/cgi
02/09/2005 18:05:52|SETI@home|Requesting 0 seconds of work, returning 1 results
02/09/2005 18:06:06|SETI@home|Scheduler request to http://setiboinc.ssl.berkeley.edu/sah_cgi/cgi succeeded

02/09/2005 18:06:07|SETI@home|Finished upload of 09dc03aa.21990.6994.142324.131_1_0
02/09/2005 18:06:10|SETI@home|Sending scheduler request to http://setiboinc.ssl.berkeley.edu/sah_cgi/cgi
02/09/2005 18:06:10|SETI@home|Requesting 0 seconds of work, returning 1 results
02/09/2005 18:06:32|SETI@home|Scheduler request to http://setiboinc.ssl.berkeley.edu/sah_cgi/cgi failed

The scheduler request to report the result is sent some 3 seconds after completing the upload.

So when you run the client manager program on look in the work tab, you don't see work result with status "Ready to report?" I do. All the time. I have had as many as 90 or more. It nice to see the list to check to see how long the work units are taking to process. But we could have that and still report them immediately. Just add another status, "Reported" and leave the units in the queue until the "Clean Queue" button had been clicked. Ofcourse that button and funtionality would have to be added. Thats what I would like to have.

---

That may be because I have always used a large queue, 10 days actually.

I seem to recall that the large queue setting affects the request for work, more than the reporting of results, but I could be wrong on that one. I'd have to have a look into it. If you're online 24/7, try reducing it down to 3 days, with ver 4.72, otherwise give 4.45 a run for a while and see how it performs. I'm also presuming that the host in question is only attached to one project, P@H.

So when you run the client manager program on look in the work tab, you don't see work result with status "Ready to report?" I do.

Nope, unless communication is deferred for some reason. (scheduler failed, won't finish on time messages etc.)

It nice to see the list to check to see how long the work units are taking to process. But we could have that and still report them immediately.

That's why we have the results list on the host details web page. ;-)

---

ralic's law of forums: Irrespective of any prior research done, you will find the solution to your question shortly after posting it to a public Internet forum, resulting in readers concluding that you have done no research on the matter whatsoever.

I seem to recall that the large queue setting affects the request for work, more than the reporting of results, but I could be wrong on that one.

I think that the next communication time is scheduled depending on the length of your queue. For instance

Sun 04 Sep 2005 06:52:52 AM PDT|ProteinPredictorAtHome|Requesting 83488 seconds of work, returning 1 results
Sun 04 Sep 2005 06:52:57 AM PDT|ProteinPredictorAtHome|Scheduler request to http://predictor.scripps.edu/predictor_cgi/cgi succeeded
Sun 04 Sep 2005 06:52:57 AM PDT|ProteinPredictorAtHome|Message from server: No work sent
Sun 04 Sep 2005 06:52:57 AM PDT|ProteinPredictorAtHome|Message from server: (won't finish in time) Computer on 98.7% of time, BOINC on 100.0% of that, this project gets 100.0% of that
Sun 04 Sep 2005 06:53:17 AM PDT|ProteinPredictorAtHome|Deferring communication with project for 1 days, 19 hours, 21 minutes, and 23 seconds

As you can see here I will have to wait for nearly two days before it will report all my work units automatically. This is even though it is uploading a completed work unit every half hour. So if I just let it go I would have about 86 completed and uploaded but unreported work units when it finally connected to report and get more work units.

If you're online 24/7, try reducing it down to 3 days, with ver 4.72, otherwise give 4.45 a run for a while and see how it performs.

The reason I went to the 10 day queue is that the project is always having trouble and people who use the short work queue are always complaining about not having work units. If I switched to 3 days I would probably only get enough work for 16 hours or so. That means always taking a chance of not getting enough work units to keep my machines busy all the time. For instance, P@H right now thinks my machine takes 52 minutes to do a work unit. When it gave me the work units it thought that it took 41 minutes to do a work unit. It actually takes about 29 and a half minutes. So now they thing my machine has too many work units and won't send be any. Two week ago they decided my machine could do work unit in 9 minutes 30 seconds and so sent me more than 700 work units. Needless to say that was too many, but only about 200 too many. All this is a round about way of saying I am going to keep my queue lenght to 10 days. As for using 4.45, I don't see how that could make any difference. I am using Boinc public release code. So my understanding is it is the same as 4.45 except with bug fixes.

I'm also presuming that the host in question is only attached to one project, P@H.

Yes.

So when you run the client manager program on look in the work tab, you don't see work result with status "Ready to report?" I do.

Nope, unless communication is deferred for some reason. (scheduler failed, won't finish on time messages etc.)

It nice to see the list to check to see how long the work units are taking to process. But we could have that and still report them immediately.

That's why we have the results list on the host details web page. ;-)

That list does not give you the amount of time you computer spent working on the work unit. Neither does the Result ID or the Work Unit ID web pages. Only the work tab in Boinc Manager gives you the CPU time for a work unit.

---

Sun 04 Sep 2005 06:53:17 AM PDT|ProteinPredictorAtHome|Deferring communication with project for 1 days, 19 hours, 21 minutes, and 23 seconds

This is why you end up with results 'Ready to report'. Communication with the project is being deferred.

Sun 04 Sep 2005 06:52:57 AM PDT|ProteinPredictorAtHome|Message from server: No work sent
Sun 04 Sep 2005 06:52:57 AM PDT|ProteinPredictorAtHome|Message from server: (won't finish in time) Computer on 98.7% of time, BOINC on 100.0% of that, this project gets 100.0% of that

And this is why.

It seems that P@H may need to update their server code, so it's a no-win until they do that. LHC is another project that gives the same message. I haven't seen this message from SAH for quite a while.
To quote a snippet from JM7 on the dev mail list:

The above message should not be generated for clients that are newer than
4.35 as the new scheduler should take care of deadline problems. I just
installed 5.0 on this machine. Instead, the server should be looking at
the slack time information that is now being sent with the request.

And to quote Dr. Anderson's reply:

Good point - I checked in a change removes the resource-share factor.
-- David

These date from 05 July 2005.

Basically, the server is throttling the amount of work you can get, instead of listening to the scheduler on the client side.

The reason I went to the 10 day queue is that the project is always having trouble and people who use the short work queue are always complaining about not having work units. If I switched to 3 days I would probably only get enough work for 16 hours or so.

Yup, it's gonna be a trade-off until the server code is updated.
Big queue &amp; Manual reporting vs. Small queue &amp; Auto reporting.

For instance, P@H right now thinks my machine takes 52 minutes to do a work unit. When it gave me the work units it thought that it took 41 minutes to do a work unit. It actually takes about 29 and a half minutes.

Yup, this is another minor irritation, but best taken up with the project in question. BOINC calculates client work ability based on the time to completion using your benchmark results and values specified by the project at wu generation. This is an ongoing saga, but best taken up with the individual project implementors.

Two week ago they decided my machine could do work unit in 9 minutes 30 seconds and so sent me more than 700 work units.

Ack! Could have been due to a bad benchmark value, or bad wu generation...

As for using 4.45, I don't see how that could make any difference. I am using Boinc public release code. So my understanding is it is the same as 4.45 except with bug fixes.

Now seeing the reason for your delayed reporting, I would tend to agree. Except that the 4.45 release is deemed stable, whereas the 4.7x release may have some latent defects. To each his own. :)

That list does not give you the amount of time you computer spent working on the work unit.

The column 'CPU time (sec)' is the number of seconds spent processing the wu, or are we missing each other?

---

ralic's law of forums: Irrespective of any prior research done, you will find the solution to your question shortly after posting it to a public Internet forum, resulting in readers concluding that you have done no research on the matter whatsoever.

That list does not give you the amount of time you computer spent working on the work unit.

The column 'CPU time (sec)' is the number of seconds spent processing the wu, or are we missing each other?

You are absolutely right. Proof positive that I should not be working so late at night. I can not tell you how many times I have looked at that and then last night to make the mistake of thinking it wasn't there.

---

[quote]
For what it's worth, the current recommended version (4.45) has a different scheduler logic code to the older client that will usually report each result immediately after it has uploaded. If communication to the project has been delayed (a red "Deferring communication with project for" XYZ time period in the messages list will alert you), then results will be reported at the next communication interval, or when a manual update is performed on the project.

I have a question reqarding 4.45 reporting results immediately. I have seen this mentioned on several project message boards and somewhere I thought someone mentioned a command line startup directive that would disable this.

The problem I am having is that with 4.45 reporting the results immedialty BOINCview (via RPC) is not logging them. In the past versions 4.19 and before I had almost every result logged, sometimes as many as 1000 or more in a month. Now I have about 1/10th of that logged but I'm still doing around the same number of work-units. This problem started when I upgraded all my hosts to 4.45. I probally could change the BOINCview to refresh every second but that would create a lot of traffic on my network. I prefer to have it refresh about every 3-5 minutes (different times for different hosts). There needs to be some delay between the upload and the report to give BOINCview time to see the completed workunit and record it.

Has anyone else seen this and found a solution other than downgrading to 4.19