Messages

If you can't repeat the problem then you can't fix it  What data can I collect to help?

The version(s) of connected BOINC client(s) might often give a clue...

In my case the default value was 50 000 IIRC. I personally do like to keep a lot of messages available, but while testing I've seen BT becoming unresponsive a couple of times for a lot of seconds, until all old messages became displayed. (As the memory usage rose by some 20 MB for the first time, I assume the display grid etc. had to be allocated, etc.)

BT keeps only one copy of the messages, so when you switch computer it may take a while to fill up. But this depends on the computer speed.

It was a single machine - localhost, no client switching. Just between BT tabs.
Filling the list from other client would load the 2 000 messages over network, whereas in my case it was some woodoo magic happening with 50 000 in-memory messages.

I'll check the machine again tomorrow, the messages should slowly fill up until.

"-Add: BoincTasks settings: Messages tab: Keep user definable number of lines."

In my case the default value was 50 000 IIRC. I personally do like to keep a lot of messages available, but while testing I've seen BT becoming unresponsive a couple of times for a lot of seconds, until all old messages became displayed. (As the memory usage rose by some 20 MB for the first time, I assume the display grid etc. had to be allocated, etc.)

The GUI still gets unresponsive for some time (20-40 seconds, masked behind "Switched, busy..." note, until the "Waiting *" sate appears again), when taking a look later at any intervals - unlike BOINC Manager, which still seems to handle all hundreds of thousands of message lines without such glitches (the message ID counter was around 120 000 now).

After restarting BT, there are just the 2 000 most recent messages (the client's cache) and the "Switched, busy..." status appears just during 2 seconds - consistent with other tabs.

My only recommendation ATM is to lower the default to 5 000 lines and leave it upon the user (with possibly noticing the consequences later, but being aware of the change and reasons).

A download isn't a task, just an attempt to get one. So it's not in the history.
No work is lost in a download error, the project will normally resend it.

It is a task, albeit incomplete.
Not all projects resend failed downloads, some send other work.
It could be an elegant way to spot frequent download errors (be it server-side, or my HW or provider).
And after noticing a lot of consecutive download errors from a particular project, I could suspend it (or set it to NNT - just no such rule yet).

The status of "Downloading Error" in task view does not match the status shown in the task properties.  It shows just "Downloading". This may or may not cause some problems in rule making as to which one is checked.

it would be nice to have other valid statuses added such as Downloading Error.  Also be able to abort task via rules.  If you get a downloading error  you must first abort the task before it can be reported to the project.

I've just noticed seeing twice a "downloaded error" task, but neither of them appeared in History (and I see there is no such task in my History, although there were such in the past), I could not report this project with All "finished tasks" and yes, also the task's status is incorrect.

In the cc_config.xml editor, the syntax checker marks "<exclusive_gpu_app>" with red as being an incorrect or unsupported tag.

Where can I see the controls for addition of an Exclusive App? Just when connected to a 6.13.x client?

OK, I can see it on other machine with 6.13.12, works and displays correctly.

With a delay, the Slovak BT 1.28 language file is finally in the upload area.

Where can I see the controls for addition of an Exclusive App? Just when connected to a 6.13.x client?

A double-click does not maximize the Threads graph.

_BoincTasks is the process run time %, so everything combined.
The others are the internal threads (BOINC only) that handle everything for that computer, like history, tasks request.

OK - the whole graph displays CPU usage of various BT parts?

I'm not quite sure what the question is, if there is any.
The graph display BoincTasks use not of any other program and it's not TThrottle related.

OK, than again my older question: the dialog allows to select _BoincTasks and all known machines. The _BT's graph displays BoincTask's CPU usage (err, does it?) What do the single machines' graphs display?

Expression "the BOINC worker threads / computer" might be understood as "number of ???? threads per computer", but that does also not bring me further

I understand it as BOINC tasks' threads. OK, quite possible, at the time just 1 CPU, 1 GPU and a few nCi tasks are active here, all throttled by up to 95%, thus the flatline.

It has nothing to do with throttling......

I know, I just wanted to say, that because of the massive throttling, the tasks combined are really consuming less than 2-3% of CPU.
But...

Another machine, 4 cores, each of 3 CPU tasks is consuming approx. 85% of a core - should be ~64% of CPU. The graph again displays its line with spikes to 0.25-0.5% - the values are inconclusive.

What does it present on the machines? The localhost is a flat line at 0% (with occasional tiny spikes).

The rest are the BOINC worker threads / computer...

I understand it as BOINC tasks' threads. OK, quite possible, at the time just 1 CPU, 1 GPU and a few nCi tasks are active here, all throttled by up to 95%, thus the flatline.

Is already fine in 5.50

What about adding a trailing colon to the temperature line? Both "Use these temperatures:" / "Použiť tieto teploty:" seem for me as an appropriate use for it.

(BTW, curious, on a machine with multiple GPUs, are more GPU lines there? (As the cards would probably reach different target temperatures.))

"-Add: Settings->Extra: Thread/process run time graph."

Just a typo in announcement: should be "Extra->Settings->Expert".

I assume it requires a functional TThrottle connection to the target machine(s)? If yes, which version? What does it present on the machines? The localhost is a flat line at 0% (with occasional tiny spikes).

_BT is around 1% with occasional spikes in 0.5-2.5% area. A minimized BG gets _BT mostly to 0%, a busy GUI forces it to 7%.