BT 1.04

[Beyond]

Additionally, it is possibly already some longer time ago (more than 3 weeks - my backup copy), but my localhost's history files begin on 22.10.2010, although my history settings were always 365+23. The remote computer's log starts correctly on 29.5.2010.

How much CPU time/day are you using with that large a history?  I found that my 13 hours/day of CPU time for BT was seriously related to History (which was set at 1 day).  Disabling History resulted in BT using almost no CPU.  Setting history of 1 or 2 hours kept CPU fairly low.  It started increasing dramatically when set to 3 hours or more.  I do run a lot of MilkyWay which generates many WUs.  Yes I tried different History options like different Maximum update times and Smart mode on and off.  For a while I even ran BoincView for a 1 day history and BT for everything else and that resulted in a total of about 2 hours/day of CPU.  Kind of a PITA though.

Can you check this with 1.04, see if there are any improvements.

Fred, your changes in v1.04 seem to have done the trick.  I increased the history to 1 day and so far BT CPU time is only 11 minutes in 4 hours run time (of course there's only 4 hours in History at this point).  I'll report back again when more time has elapsed.  To answer Pepo's question, it looks like I'm averaging 5-6 WUs completed per minute.

[Pepo]

...Setting history of 1 or 2 hours kept CPU fairly low.  It started increasing dramatically when set to 3 hours or more.

I would not set my history refresh time that high (except when being absolutely desperate ), because it would completely miss all tasks with a shorter runtime (my switching time is also around 2 hours).

You forgot your morning coffee again.  It's not history refresh time, it's total history log kept.

Ah we are talking about different 2 hours, from the same beginning? 
Indeed, no coffee today

[Pepo]

One hour ago I've observed my SETI cuda task, approaching its end. Now it is gone, but the History tab weirdly states it was finished yesterday and reported now, 1/2 hour ago:

SETI@home   6.10 SETI@home Enhanced (cuda_fermi)   04mr11aa.27560.5384.3.10.174_1   Elapsed(CPU): 03:51:40 (00:06:03)   Finished: 30.05.11 17:16   Reported: 01.06.11 10:54   Use: 0.56C + 1NV   Reported: OK

While the Messages log says:

6573   SETI@home   01.06.11 10:30   [checkpoint] result 04mr11aa.27560.5384.3.10.174_1 checkpointed   
6670   SETI@home   01.06.11 10:34   [checkpoint] result 04mr11aa.27560.5384.3.10.174_1 checkpointed   
6783   SETI@home   01.06.11 10:38   [checkpoint] result 04mr11aa.27560.5384.3.10.174_1 checkpointed   
6913   SETI@home   01.06.11 10:43   [checkpoint] result 04mr11aa.27560.5384.3.10.174_1 checkpointed   
6956   SETI@home   01.06.11 10:45   Computation for task 04mr11aa.27560.5384.3.10.174_1 finished   
6958   SETI@home   01.06.11 10:45   Sending scheduler request: To fetch work.   
6959   SETI@home   01.06.11 10:45   Requesting new tasks for NVIDIA GPU   
7029   SETI@home   01.06.11 10:47   Scheduler request completed: got 1 new tasks   
7167   SETI@home   01.06.11 10:52   Sending scheduler request: To report completed tasks.   
7168   SETI@home   01.06.11 10:52   Reporting 1 completed tasks, not requesting new tasks   
7182   SETI@home   01.06.11 10:52   Scheduler request completed   
7925   SETI@home   01.06.11 11:16   Starting task 02ap11ab.3996.4157.11.10.161_1 using setiathome_enhanced version 610   

Otherwise BT is displaying correct times (tasks' Deadlines, Times received). There were no time jumps in the OS.

[Beyond]

Fred, your changes in v1.04 seem to have done the trick.  I increased the history to 1 day and so far BT CPU time is only 11 minutes in 4 hours run time (of course there's only 4 hours in History at this point).  I'll report back again when more time has elapsed.

1 hour 54 minutes CPU in 24 hours with History set to 1 day.

[fred]

1 hour 54 minutes CPU in 24 hours with History set to 1 day.

Of course this depends what the time is all about.
1 hour on a 8 core is something different from 1 hour on a single core.

[Pepo]

2:54 hours in 2 days on 4 cores, 365+23 - albeit with just a handful of tasks.

[Beyond]

1 hour 54 minutes CPU in 24 hours with History set to 1 day.

Of course this depends what the time is all about.
1 hour on a 8 core is something different from 1 hour on a single core.

Athlon 620 quad.  Big improvement, with v1.03 it was 13 hours.

[Pepo]

...my history settings were always 365+23.

How much CPU time/day are you using with that large a history?

Today after 5 hours run time (localhost only) the CPU consumption is 22 minutes -> under 2 hours daily. Maybe because of fairly low number of longer-running tasks, I have mostly some 15 active and 5-10 ready to start. My system is finishing merely 15-30 tasks daily.

I could tell more after running for a couple of days uninterrupted, or sometimes make a test with a 1 week history buffer.

To try the CPU consumption out, I've lowered my history (4100 lines in the local history file) from 365+23 to 15+23, assuming that it will keep approx. 150 lines in the local history file. Got the warning, but nothing obvious happened in the History tab - kept until October 2010. A look in the file - it got shortened by 1/2 (to 2080 lines). After restarting BT, the history finally got clipped, both in the History tab and file - to today (for local machine, 5 finished results, some active results) or two left results from a slow remote machine (but! they are from 25.12.2010 and 11.10.2010!).

I've tried the "keep history for" value down to 5 days, but the file got never clipped to much less than 192 kB (1080 lines). For 3 days, I've got 102 kB (580 lines), for 2 days 58 kB (330 lines), still approx. some 15 days of results. The History tab was still complete, until restart. Finally I've upped the limit to 20 days and restarted BT again - history file went down to 35 kB (200 lines) and the History tab displayed 63 results for the past 3 days (=2d+23) and 120 more results from 13.5.2011 down to 24.10.2010 - approx. 1 result for each 2-3 days Even after multiple restarts. My history is set to 20 days.

The shortening of the history smells to me somehow indeterministic?

Never mind, I'll be checking the CPU consumption now. History is set to 20 days, the file contains past 3 days + some dust from previous half year...
BTW, the computer name string size rises darn fast! )

[Pepo]

...my history settings were always 365+23.

How much CPU time/day are you using with that large a history?

Today after 5 hours run time (localhost only) the CPU consumption is 22 minutes -> under 2 hours daily. Maybe because of fairly low number of longer-running tasks, I have mostly some 15 active and 5-10 ready to start. My system is finishing merely 15-30 tasks daily.

I could tell more after running for a couple of days uninterrupted, or sometimes make a test with a 1 week history buffer.

... I'll be checking the CPU consumption now. History is set to 20 days, the file contains past 3 days + some dust from previous half year...

After 3 hours, BT mostly idle except a few minutes at the beginning and now, CPU usage 1:22 minutes
Let's see tomorrow.

[Pepo]

... I'll be checking the CPU consumption now. History is set to 20 days, the file contains past 3 days + some dust from previous half year...

Date Time		Runtime		CPU usage
June 01, 2011, 08:39:36 PM		3 hours		1:22 min
June 02, 2011, 09:44:36 AM		16 hours		13:23 min

[idahofisherman]

I found an inconsistancy in the way the update completed tasks works.  If you block off the ready to report WUs and use the right mouse button to get to the menu and press "Project UPdate" the timer for all tasks is reset to the maximum time to update.  If you go to the projects drop down menu, and press the report all  completed tasks, the timer is not reset.   This may be the way its supposed to work. I just noticed it today.  Its no biggie, just  thought I would bring to your attention.  Keep up the great work.

[fred]

I found an inconsistancy in the way the update completed tasks works.  If you block off the ready to report WUs and use the right mouse button to get to the menu and press "Project UPdate" the timer for all tasks is reset to the maximum time to update.  If you go to the projects drop down menu, and press the report all  completed tasks, the timer is not reset.   This may be the way its supposed to work. I just noticed it today.  Its no biggie, just  thought I would bring to your attention.  Keep up the great work.

Strange on my computers it shows updating in Projects.
And it's doing the same thing, except when there are not task to report it skips the project, otherwise it does an project update.

[Corsair]

again with export colours, looks like that some colour patterns are not exported or imported, and referring to projects colours, not transferred from one to another, as for the 4th and up project/computer depending of the view if combined or not.

the other thing should be that when exported the colour settings file should be asked the path for save it, and when imported should be asked for the path of importing, instead the default one that sometimes is not easy to remember/find.

this I've noticed as I've retired one computer "the server" for BT and upgraded with a new one, and wanted to import colours and some of then were missing.

I think that it's still in the wish list for of all settings + computer layout of an old installation as export/import.

[Dirk]

If I want to stop BOINC/S@h I disable computation/network in BoincTasks. Then finish client and exit BT. I do this for to be sure, that no UL/DL/scheduler contact is running and a well checkpoint is set for CUDA WU. In past I suspended a CUDA WU in the preparation time on CPU, when I restarted BOINC the CUDA WU finished immediately with an error.

If I start BT and start the client, I can't enable computation/network.
I need to do then exit of BT, restart BT and then the menu is available and I can enable again the computation/network.

Maybe a BUG?

[fred]

If I start BT and start the client, I can't enable computation/network.
I need to do then exit of BT, restart BT and then the menu is available and I can enable again the computation/network.

It may take some time before the menu is available. Initially it's grayed out and becomes active after communicating with the client.