I normally have BOINC Manager open on the Tasks tab to see if anything needs doing/reporting. When something does, I go to the projects tab and do the reporting act. When that is done, no projects are highlighted on the list. However, if I then go back to Tasks and return to Projects, the last project I did a report for is highlighted again.

I did say this was trivial...

---

Wave upon wave of demented avengers march cheerfully out of obscurity into the dream.

Assuming you're using Windows:

In Windows, highlighting is applied to the control that has 'focus'. When you select a project, the project list control has focus, and you see highlighting.

When you click the 'update' button, the button takes the focus and the list loses focus - so the highlighting is removed (by Windows), although the project remains selected in the list.

When you switch from the projects tab to any other tab, and back again, BOINC sets the focus to the list control - and Windows highlights the selected row.

That's how Windows works these days. Complain to Bill Gates, not us.

>>> Complain to Bill Gates, not us.

Complain? I was simply pointing out something I noticed this morning in BOINC Manager. I am SO SORRY I BOTHERED.

---

Wave upon wave of demented avengers march cheerfully out of obscurity into the dream.

Sorry, sometimes my attempts at English humour don't translate too well. I should know that by now.

Unless you're on dialup or another non-persistent connection, why do you need to update manually? BOINC Manager is designed to do everything in the background without user intervention.

---

My Detailed BOINC Stats

I have noticed that some projects do report themselves, they upload, and they go. Others do not do that, they upload and go into a Ready to report state. So, I report them. It could be that they will report themselves after a period, it would make sense, I've seen that when I, for example, come home from a holiday, there are not pages and pages of jobs waiting to go. I don't know how long that period is. It is not a problem for me to report them if I see them in that state. At this moment, I have a Milky Way, a CSG and an Einstein job in the Ready to report state, I'll leave them... but it is an automatic reaction when I come to a system to do the reporting without thinking really....

---

Wave upon wave of demented avengers march cheerfully out of obscurity into the dream.

Many years ago, the delay between 'ready to report' and actual reporting was a maximum of 24 hours. In recent versions of BOINC, that's been brought down to 1 hour maximum. There are many other triggers for a possible earlier report (like the need for new work), so you shouldn't delay the science unduly by not report reporting manually.

It would be good to have immediate reporting as an on/off option on the Manager menu.

---

Wave upon wave of demented avengers march cheerfully out of obscurity into the dream.

I disagree, as then everyone turns it on and the amount of scheduler contacts increases by thousands of times over how it's done now. Remember that the projects rather have that you contact their scheduler server with a load of tasks to report, rather than every time a task is ready to report, because it severely cuts down in the amount of contacts their server has to do in a minute. The overhead on the server (use of CPU, RAM, hard drive etc.) is the same between reporting 100 tasks and 1 task, but where 100 single reports take that overhead, the project rather has to use that overhead once for those 100 tasks.

---

Surely, reporting at the same time as uploading would reduce the number of contacts since the contact has already been made to upload the result.

The automatic reporting was recently changed to report after an hour. That also reduces the number of results per report.

It is still not clear to me why reporting is necessary at all.

---

Wave upon wave of demented avengers march cheerfully out of obscurity into the dream.

Surely, reporting at the same time as uploading would reduce the number of contacts since the contact has already been made to upload the result.

It's two different systems. Uploading doesn't use the scheduler, but is merely a transfer of data from your computer's hard drive to a hard drive on the upload server.
Reporting uses scheduler, which checks what you're trying to do, then points to the database server where it's reported which task(s) you've finished, and can do checks such as whether all the tasks you were sent in the past are still there - and if not, and the project has this enabled, resent the lost tasks.

These scheduler contacts can at the same time request work, because that also uses the database server, as the work has to be registered against your account. The download server then transfers data from its hard drive to your hard drive, same as with an upload.

---

Which system on the server is processing the transaction is not the issue - it is the number of contacts made.

---

Wave upon wave of demented avengers march cheerfully out of obscurity into the dream.

Actually, which system does matter. On the larger projects like CPDN and Einstein, the upload server (where the files go) and the database server (where the housekeeping is done - keeping track of tasks, processing time, and credit) may be on different machines - sometimes even on different continents. Because the transactions are so different, there's no way of 'combining' them as you suggest.

Some projects do "auto report". I see that Acoustics does, I see a task go into waiting to report, and before I can switch to the projects tab, it goes.

---

Wave upon wave of demented avengers march cheerfully out of obscurity into the dream.

GPUGrid does that too. You'll probably see the tag

<report_immediately/>

in the <result> section for their workunits - in other words, it's an option set on their server and sent out with the tasks.

There is another, relatively new, feature in BOINC. If you set 'No new tasks' for a project, that automatically sets 'report results immediately' for that project.

This was done to ensure that completed work was reported in a timely fashion if, for example, the user was preparing to go on vacation, or to retire a computer. Any work in the queue that was run and completed before the holiday/retirement would be reported before the machine was shut down.

With the availability of 16C/32T and 18C/36T processors becoming a reality, it is going to be hard to get the running tasks on the screen let alone the numerous "Ready to reports". I think the ability to set this easily in the manager would be a good idea. Globally or possibly per project.

It looks like the mechanism exists already, if I've read the above right, so I can't imagine that a lot of work would be necessry.

---

Wave upon wave of demented avengers march cheerfully out of obscurity into the dream.

The feature exists and is fully operational: it is documented on the client configuration page of the user manual:

<report_results_immediately>0|1</report_results_immediately>
If 1, each job will be reported to the project server as soon as it's finished, with an inbuild 60 second delay from completion of result upload. (normally it's deferred for up to a day, so that several jobs can be reported in one request). Using this option increases the load on project servers, and should generally be avoided. This is intended to be used only on computers whose disks are reformatted daily.

Reading that back, I see the (outdated) reference to a one-day delay: I'll change that. I think the 60-second delay has also been removed, but I'll check further before changing it.

The only features which do not exist are the per-project settings, and a GUI control for setting it. Given the general advice to avoid the setting, I expect that the policy of setting the feature to 'off' by default will remain in place.

You need to think of BOINC as an integrated project, combining both the client that you run, and the servers that manage the work supply and return. Sometimes, decisions are made which favour the server side of the balance, and assist project administrators who have to purchase, maintain and manage those servers. This seems to be a case in point: opening a project database, locating task and workunit records, and updating them is a computationally expensive task which is most efficiently performed in batch mode (Rom Walton once wrote a detailed blog post explaining the costs, but I don't have a link handy).

<report_results_immediately>0|1</report_results_immediately>

I cannot see that in cc_config.xml. In fact, the xml doesn't look right at all. <options> opens, and the list starts, but the last is <process_priority_special>-1</process_priority_special>, the next line in the file is <proxy_info>, ie. <options> is not closed?

>>> This has gone way off the 'trivial' of the OP.

It happens, a question of trivial significance gets asked answered...end? Well, no, it gets extended by a secondary question asked in the thread by another.

---

Wave upon wave of demented avengers march cheerfully out of obscurity into the dream.

<report_results_immediately>0|1</report_results_immediately>

the next line in the file is <proxy_info>

After the intrusive and badly formatted <proxy_info> block (9 lines plus terminator), the <options> list should continue with the 'R' section of the alphabet - <rec_half_life_days> is next on my version. The file ends normally with proper XML termination

        <vbox_window>0</vbox_window>
    </options>
</cc_config>