My BOINC 6.12.33 has an almost permanent (it disappears occasionally) IPv4 loopback exchange (between boincmgr and boinc) of ~90000 Bps. Is this a fault or simply to annoy people?
Please reveal how to get rid of it.
Thanks, Raffia

Eithier click 'Show active tasks' only, or Shut Boinc Manager down while still leaving the client running,

Claggy

Boinc Manager does not reveal the loopback conundrum in any way; therefore manipulating boincmgr displays makes no difference.

The loopback load is revealed by the Resource Monitor (W7).

Killing boincmgr deprives me of the possibility to overrule its sometimes strange scheduling.

The only way out seems to be going back to an older version...

Raffia

Boinc Manager does not reveal the loopback conundrum in any way;

Nobody has said that.

therefore manipulating boincmgr displays makes no difference.

But it should, since Claggy's suggestion can vastly reduce the amount of traffic between BOINC manager and client.

Killing boincmgr deprives me of the possibility to overrule its sometimes strange scheduling.

You are not supposed to kill it, just exit it when not needed. If you think you have to overrule something, restart the manager for the duration of that task.

Gruß,
Gundolf
[edit]Why are you worrying about the loopback traffic anyway? It's strictly local![/edit]

---

Computer sind nicht alles im Leben. (Kleiner Scherz)

And reverting to an older version won't help - they all work the same way. If you haven't noticed it before, that's because you haven't been looking - it isn't new to v6.12.33

I have verified that already! My main point is: Why waste cycles on trivia, when there are nice projects that can make better use of those.

Further investigation shows that the phenomenon only occurs on my 64bit AMD PC. The difference with my 32bit Intel PC is exactly 2% of a processor's capacity.

Is there a hidden agenda somewhere?

Raffia

Of course there is. It's there to add to conspiracy theorists their convoluted mindsets. :-D

My main point is: Why waste cycles on trivia, when there are nice projects that can make better use of those

Stop trying to see your whole list of tasks in real-time then. Use the button, as said earlier in this thread, to show only your active tasks, not all tasks. Then that constant checking will go away.

What you see is the real-time update of all tasks in the Tasks tab. The progress and timers of the ones being active and the others being updated when tasks are finished and their estimated run time is updated. This happens through an RPC on localhost (127.0.0.1) via TCP/UDP port 31416.

The RPC can at most show 1,000-1,500 tasks per second. Any more and there's more data than can fit in the one second and then the Manager will lose contact with the client.

Even if you have way less than 1,000 tasks in the list, but you want to show all of them anyway, just because you can, it will give a strain on the update. That strain shows as CPU cycles. And thus, really, if you do not want to let the CPU use many of those cycles, then don't show all tasks you have.

---

Now I get it:

All (Boinc-)displays are refreshed every second in their entirety even if only 1% has changed and regardless if anybody is looking (= its Window is opened).

Maybe Build 7 should include Schrödinger's Display (only valid if visible)...

Raffia

That's worth thinking about.

The way I understand it, every second the Manager (the bit we can see) asks the Client (the worker in the background) to describe itself, and say what it's doing. The request is trivial - it'll be the data (text) in the reply which comprises the vast bulk of the loopback traffic.

The nature of the traffic is described in GuiRpc - and in that, I only see one get_results(RESULTS&).

That leads me to question Claggy's suggestion. It seems to me that the Manager must request (and receive) data for all results, whether or not 'active tasks only' is selected. Perhaps it's the manager which simply discards data relating to inactive tasks: the time-saving allowing screen refresh at 1 Hz might only be in the text-to-graphics rendering in the manager (which is plausible - GUIs always place heavy computational demands on any system. That's why GPUs were invented).

The complete 1-second cycle comprises:

Render binary data in memory into text (XML) format
Exchange text data between two applications by loopback
Parse text data, and render it graphically

If I'm right, and only one of those steps (the final one) is controlled by the 'active tasks' button, then a further optimisation is obvious. A further GUI_RPC command, get_active_results(RESULTS&) - which should be trivial to derive from the existing code - would reduce the time taken for both the initial memory-to-text conversion, and the communications (in both programs), in addition to the existing GUI savings.

Or maybe that's been done already, and it's only the documentation which is out-of-date - wouldn't be the first time that has happened in the history of software development :-)

Adopt Adapt Improve

Raffia