The Ready to Report (RtR) is the 2nd step in a 2 part reporting cycle to ensure that a completed Task's files are
properly transmitted, cross-verified as being totally correct received by the servers and confirmed. The RtR
shows in the Tasks Tab of the BOINC manager GUI (Advanced view), once the data files of the Task (aka Result)
have been received by the servers in proper order.

Upon transmission of the RtR to the Scheduler (a different part of the server system processes), a brief Acknowledgment
will be seen in the Tasks tab Status column.



After, the Task entry in the client is cleared and all traces in the local tracking files, except for the Message and local
job Logs (job_log_www.worldcommunitygrid.org.txt) is removed.

For purposes of efficiency, the Ready To Report is send on the next 'Scheduled' contact with the servers and are
per the below table.

• New work is needed to backfill the cache/additional buffer. Completed work will be reported at the same time.
  Sample message log entries:
  

  15/12/2007 10:29:23|WCG|Sending scheduler request: To fetch work.
                          Requesting 39440 seconds of work, reporting 6 completed tasks
  15/12/2007 10:29:28|WCG|Scheduler request succeeded: got 4 new tasks

• The Result has been in the Ready to Report status for 24 hours. (New for v5.10.14)
  
• The Result is completed closer than 24 hours before deadline (often High Priority Processing goes along)
  
• The Result Deadline is nearer than the next Work Buffer ("Connect to network about every 'x' days") setting. (New for v5.4.xx)
  
• The Result has been in the Ready to Report status longer than the size of the Work Buffer (Connect to network
  about every 'x' days") setting. (Removed in v5.10.14 and later)
  
• If the Update button is pushed [repeated hitting is pointless as a forced back-off is inserted to stop server flooding]
  
• If a scheduled suspend of Network or Computing is set: All results completing from 30 minutes before pausing.
  
• If work fetch has been suspended for the subject project: "No New Work"
  
• If "net_status.have_sporadic_connection" will report immediately. (possibly for dialup-users only!)
  
• If the Minimum Work Buffer level has been reached [New for v7.0]
  
• When the project server scheduled connect time expires. ~48 hours for WCG.
  
• When the Account Manager (BAM or GridRepublic) make an update request.
  
• For Android Only!: Immediately upon completion of the Result file(s) upload. (New for v7.2.14)
  
• If a 'trickle' is uploaded or downloaded to/from the server (not applicable to WCG and only for projects with partial job progress reporting)
  Sample Message Log Entries:

  15/12/2007 10:09:37|CPDN|Sending scheduler request: To send
  trickle-up message. Requesting 0 seconds of work, reporting 0 completed tasks

The speed of reporting is impacted e.g. by the Connection Time setting in the Device profile and other client
scheduling activities. When a Connect Time of 2 days is set in order to be able to buffer more work, there
is no rush to update the server side scheduler, thus the RtR clearing would be postponed up to when
the 'Connect Time' of 2 days has passed. When a permanent internet connection does exist though and is
open, the client will try to push out the Task Result Files, so at least a backup exists on the server side, still
there being no need to update the server scheduler. The client did set that Connect Time after all.

There is of course the Projects Tab 'Update' button that opens / tries opening a connection with the server to push out any results
and force the RtRs up. This usually results in the desired action. Better is to opt for the WCG recommended short connect time
defaulting to 0.3 days (7.2 hours) [Minimum Work Buffer in v7.x] and use the local 'Maximum Additional Work Buffer' days preference option
( = web device profile option "cache") to obtain extra work in the Tasks queue. This will clear the RtR's more frequently without unnecessary extra
scheduling daemon contacting.

When RtR's are not cleared or new work is not fetched, it is possible that the client got confused [The Event Log prints 1 of about 14 reasons].
Frequent changing of profile settings & local preferences and repeated panic states (see discussions on High Priority / Earliest D Deadline First (EDF) processing,
which can cause such conditions to develop). BOINC needs 1 or 2 weeks to find it's balance and understand *particularly* if multiple distributed computing grids are attached to the client. Best is to decide on what's wanted, make the changes and leave it be. Resist the urge to micromanage

Occasionally too many Ready to Report accumulate [for instance having completed many results during an offline period or longer upload fail period, then uploading them]. The solution is to restrict the number of simultaneous sends of RtR to the server by introducing a cc_config.xml entry: <max_tasks_reported>50</max_tasks_reported> . Follow this member post by Ingleside for the how-to: http://www.worldcommunitygrid.org/forums/wcg/viewpostinthread?post=440062

Related Messages

• Completed result XXX refused: result already reported as success
  
  This message is send from the servers when, as the text indicates, the task RtR was received in good order in a previous transmission.
  During the communications the last 'acknowledged' step [see top screenshot] of the Ready to Report
  scheduler confirmation somehow got lost between the server and the client, leaving the record to show in the client's task window. Eventually the line, example below,
  should clear by itself after next successful connection.
  
  27/5/2009 01:27:56|WCG|Message from server: Completed result faah6284_ZINC04993862_xmdEq_Model6Xapo_01_0 refused: result already reported as success
  
  Check the Result Status page to see what condition the task is showing. Good chance is that the work unit is already marked Valid.
  
  Those who have the appropriate log flag activated in the cc_config.xml would see an entry in their client message window confirming the successful transmission. Example:
  
  15/09/2009 20.57.23 WCG [sched_op_debug] handle_scheduler_reply(): got ack for result flu10801k0594_100103_0
  15/09/2009 20.57.23 WCG [sched_op_debug] handle_scheduler_reply(): got ack for result flu10801k0595_100363_0
  15/09/2009 20.57.23 WCG [sched_op_debug] handle_scheduler_reply(): got ack for result flu10801k0614_100291_0
  

Return to the Start Here FAQ index