BT 1.26

[coolstream]

First chance to test the inbuilt update function (1.25->1.26)

Things went very fast and smoothly. I was worried about having to configure the update to run as Administrator, but see that this is done as part of the update procedure. Congrats on a job well done!

Now to test some of the new features...

[Pepo]

I've just upgraded BT 1.25->1.26 on second Win 7 x64 machine. It took very unusual 2 minutes long for the BT process to create its additional threads (in addition to the initial one), allocate more than the initial 5.4 MB memory and actually start working. I do not remember observing something similar on the previous machine.

The gap is also in the logs (empty lines are discarded):

Code (08-11-2011.log) Select Expand

Start logging
08 november 2011 - 18:13:05 BoincTasks version: 1.26
08 november 2011 - 18:13:05 Language ---- User: 1051 (SKY), System: 1051 (SKY), Selected: 0 () Used: 1051 (SKY)
08 november 2011 - 18:15:08 Maximum number of computers: Unlimited

Code (BoincTasks Startup.log) Select Expand

11/08/2011, 18:13:04 -- Startup: BoincTasks Version: 1.26
11/08/2011, 18:13:04 -- Set exeption handler
11/08/2011, 18:13:04 -- Read arg: /SHOW
11/08/2011, 18:13:04 -- Language detection
11/08/2011, 18:13:04 -- Language registry: 0
11/08/2011, 18:13:04 -- Language selected: 0
11/08/2011, 18:13:04 -- Read translation
11/08/2011, 18:13:04 -- Close translation, OK
11/08/2011, 18:13:05 -- Started logging
11/08/2011, 18:13:05 -- Open translation override
11/08/2011, 18:13:05 -- Close translation override, OK
11/08/2011, 18:13:06 -- User: 1051 (SKY), System: 1051 (SKY), Selected: 0 () Used: 1051 (SKY)
11/08/2011, 18:15:25 -- Startup finished

[Pepo]

Add: Transfer graph for BOINC V 7 (and 6.13.xx)

In the Data Transfer graph I've selected the (pre-6.13) localhost client (6.12.41) - the graph area was off course empty. After clicking or double-clicking there the whole dialog turned into just a gray area without controls, keeps so after reopening the dialog. I'll possibly have to restart BT to fix it.

With 6.13.10 on other machine the graphs worked just fine.

[fred]

I've just upgraded BT 1.25->1.26 on second Win 7 x64 machine. It took very unusual 2 minutes long for the BT process to create its additional threads (in addition to the initial one), allocate more than the initial 5.4 MB memory and actually start working. I do not remember observing something similar on the previous machine.

Probably deleting some files. I will add some more startup logging in the next version. This way you can see what's going on in the 2 minutes.

[fred]

Add: Transfer graph for BOINC V 7 (and 6.13.xx)

In the Data Transfer graph I've selected the (pre-6.13) localhost client (6.12.41) - the graph area was off course empty. After clicking or double-clicking there the whole dialog turned into just a gray area without controls, keeps so after reopening the dialog. I'll possibly have to restart BT to fix it.

This is the same as in all graphs, double click = fill graph, double click again and.......
But I will change this.

[Pepo]

I'll possibly have to restart BT to fix it.

This is the same as in all graphs, double click = fill graph, double click again and.......
But I will change this.

You've just fixed it 

I actually do like the zoom, I've been really missing it on graphs.
Maybe some unobtrusive Double-click to enlarge/restore graph in one graph corner would be just sufficient?

[fred]

Maybe some unobtrusive Double-click to enlarge/restore graph in one graph corner would be just sufficient?

I will.

[Pepo]

[...]  BT (1.25 connected to local Win x64 6.13.9 client) somehow got out of order. These running tasks were suddenly not green-highlighted, their Status column described them as "New" or "New - Suspended by user", instead of "Running" or anything else. [...] In the Messages tab, there was all rosa-highlighted and in the message ID column, weird numbers flashing between zero and something huge or negative were jumping around; date-time column contained just "--":

5 minutes later all was back to normal.

Noticed again with BT 1.26 connected to 6.13.10 localhost, after raising up BT's opened window from somewhere below other apps. It took 1/2 minute of full core CPU usage. I've noticed just Tasks and Messages tabs with the same symptoms, then it was back to normal.

It happened some 1/2 minute after the last event in log, probably just after raising the window:

Code (08-11-2011.log) Select Expand


08 november 2011 - 21:11:19 User switching ---- Session Lock
08 november 2011 - 21:14:18 User switching ---- Session Unlock
08 november 2011 - 21:26:32 User switching ---- Session Lock
08 november 2011 - 22:11:17 User switching ---- Session Unlock
According to the CPU and I/O usage graphs (taken with 2 sec sampling), BT was just correctly regularly communicating with the client. 22:11:43-22:11:49 the first small CPU spike appeared. 22:11:49-22:12:18 was using one full CPU core and the I/O was just nearly continuous reads (instead of usual short R+W spikes), but not larger amounts as usual. 22:12:20-22:12:24 the second small CPU spike, I/O R+W spikes appeared just as usual.

And again

Code Select Expand

weird state:
SETI@home 6.10 SETI@home Enhanced (cuda_fermi) 08ap11ab.4382.4157.16.10.247_1 - (-) 100.0000 0.0 0.65C + 1NV - 13d,04:37:00 New
correct state:
SETI@home 6.10 SETI@home Enhanced (cuda_fermi) 08ap11ab.4382.4157.16.10.247_1 00:24:25 (00:01:56) 100.0000 7.9 0.65C + 1NV - 13d,04:35:38 Ready to report


While it is happening, History refresh cycle is 3 seconds. Prefs are 4-15 seconds. Thus the idea with SETI task at 100%.

And again, all available tasks:

Code Select Expand

SETI@home 6.10 SETI@home Enhanced (cuda_fermi) 08ap11ab.4382.4157.16.10.247_1 - (-) 100.0000 0.0 0.65C + 1NV - 13d,04:35:11 Nová
surveill@home 1.08 crawler wu_1320753004_16363_0 00:10:15 (00:00:01) 62.5000 0.2 0.025C 00:06:23 02:49:09 Nová, Upozornenie na termín
FreeHAL@home 1.93 FreeHAL fh_nci_0_43467536_94_0 01:48:29 (01:42:14) 45.1389 94.2 0.025C 01:50:04 05d,17:03:15 Nová
WUProp@Home 3.27 Data collect version 3 (nci) wu_v3_1319038646_648351_0 01:16:42 (00:00:02) 42.5414 0.1 0.025C 01:52:57 04d,22:42:43 Nová
PrimeGrid 6.09 Cullen (LLR) llrCUL_104730545_3 03:05:17 (01:20:02) 1.3849 43.2 21d,12:02:10 12d,19:40:10 Zastavená užívateľom, Upozornenie na termín


I've tried to modify the History refresh lower time bound - the refresh obeyed it. The "less accurate" checkbox had no influence.

Now BT is just in this weird state.

[Pepo]

The BT 1.27 does also often come into such weird state.

As also with 1.26, the high CPU usage does not happen always, just sometimes. But clear indications are

• no running tasks highlighting in Tasks tab and all tasks being "New", empty Checkpoint column, other columns are somewhat correct,
• Messages tab lines are constantly rosa-highlighted, the whole area gets refreshed each 1-2 seconds, no timestamps are displayed, messages' IDs are all just random numbers or zeros,
• History tab refresh countdown is the lower preference bound

[Pepo]

My local TTh 5.43 crashed yesterday, no idea why.

BT was still displaying the CPU temperatures in Tasks tab during the following 3/4 day, until I've confirmed the WER dialog. Maybe TTh was still partially communicating with BT? I've forgot to check, whether the temperatures do somehow change according to the CPU load, but I can confirm that TTh was unresponsive and neither BT's Temperature nor BT's TThrottle dialogs could connect to TTh.

And even after the TTh process vanished (and the temperatures column got emptied afterwards), the Computers tab's TThrottle column still lists 5.43, indefinitely, although the process is gone hours ago. I've noticed this bug already long ago, but never waited that long with subsequent TTh start.

[fred]

My local TTh 5.43 crashed yesterday, no idea why.

BT was still displaying the CPU temperatures in Tasks tab during the following 3/4 day, until I've confirmed the WER dialog. Maybe TTh was still partially communicating with BT? I've forgot to check, whether the temperatures do somehow change according to the CPU load, but I can confirm that TTh was unresponsive and neither BT's Temperature nor BT's TThrottle dialogs could connect to TTh.

And even after the TTh process vanished (and the temperatures column got emptied afterwards), the Computers tab's TThrottle column still lists 5.43, indefinitely, although the process is gone hours ago. I've noticed this bug already long ago, but never waited that long with subsequent TTh start.

On a crash, who knows what happens, the temp should normally go away.
But the crash wasn't in the main program as far as I can tell, so the communication part could still be running.
The version stays there, because usually that doesn't change. But it should say disconnected.