Quote from: fredAdd: A rule that triggers when a computer or all computers loose connection.A "Connection =<>" rule was probably not intended - just the equal sign?
1.04
TheMachineNameTheMachineNameTheMachineName............TheMachineNameheMachineNameTheMachineName
BoincTasks History
Project Application Version .......
Quote from: Pepo on May 30, 2011, 04:17:05 PMAdditionally, 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.
Quote from: Beyond on May 30, 2011, 07:31:12 PMIt is usually not that bad (although I remember it being more than I'd like, in the past, but I do not remember any hard facts). 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. One more reason could be that my history is (today again) smaller than 1 year, thus there is no need to discard older entries from the files (OK, I think that the files are being completely written anyway) and if the History tab is written correctly, there is also no need to do any (major) sorting upon adding new data for newly coming running and finished tasks... Thus, thinking naively, the CPU consumption should, in my opinion, depend just on the number of active tasks and slightly on the (maintained) file length, but not primarily on the (displayed) history length?Quote from: Pepo on May 30, 2011, 04:17:05 PMAdditionally, 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.
Quote from: Beyond on May 30, 2011, 07:31:12 PMCan you check this with 1.04, see if there are any improvements.Quote from: Pepo on May 30, 2011, 04:17:05 PMAdditionally, 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.
Quote from: Pepo on May 30, 2011, 04:17:05 PM
After using a 3 weeks old copy of history file, it was accepted, but the initial lines suddenly contain one overlong string in form [/list]Code Select1.04
TheMachineNameTheMachineNameTheMachineName............TheMachineNameheMachineNameTheMachineName
[/quote]
I checked this, and it was probably a leftover, of times long gone.
At this point all elements dump the computer name, this was probably for a test and I forgot to remove it.
In 1.05 the computer name is only written once, from the first element. But it's not used at all, just for human use.
Never a good idea to let the file grow unnecessarily.
Quote from: fred on May 31, 2011, 06:48:13 AMIndeed ;DQuote from: Pepo on May 30, 2011, 04:17:05 PMI checked this, and it was probably a leftover, of times long gone.
- After using a 3 weeks old copy of history file, it was accepted, but the initial lines suddenly contain one overlong string in form
Code Select1.04
TheMachineNameTheMachineNameTheMachineName............TheMachineNameheMachineNameTheMachineName
At this point all elements dump the computer name, this was probably for a test and I forgot to remove it.
In 1.05 the computer name is only written once, from the first element. But it's not used at all, just for human use.
Never a good idea to let the file grow unnecessarily.
Quote from: Pepo on May 30, 2011, 08:52:24 PMAfter 20 hours the CPU consumption is 21:49 kernel + 57:51 user = 1:19:42 total, which extrapolates to 1 1/2 hours daily. (History settings is 365+23, 3-20 seconds, smart checked. The files' lengths are 4050 + 50 lines now.)Quote from: Beyond on May 30, 2011, 07:31:12 PMToday after 5 hours run time (localhost only) the CPU consumption is 22 minutes -> under 2 hours daily. [...]Quote from: Pepo on May 30, 2011, 04:17:05 PM... my localhost's history files begin on 22.10.2010, although my history settings were always 365+23...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...
I could tell more after running for a couple of days uninterrupted, or sometimes make a test with a 1 week history buffer.
Quote from: Beyond on May 30, 2011, 07:31:12 PMI 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). But "It started increasing dramatically when set to 3 hours or more" makes me really :o wonder - this CPU usage increase should not depend on the history IMHO...
...Setting history of 1 or 2 hours kept CPU fairly low. It started increasing dramatically when set to 3 hours or more.
Quote from: Beyond on May 30, 2011, 07:31:12 PMApproximately, in a rough average: how much active/all tasks do you have and what is their run time? How many tasks are finished daily (or hourly, does not matter)? I assume I'm playing in a diffident league with my 15+10 tasks :)) My system is finishing merely 15-30 tasks daily, thus hard to compare the histories' behavior without knowing its implementation and possible reasons for higher CPU usage.
I do run a lot of MilkyWay which generates many WUs. 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.
QuoteFinished receiving metadata for 'setup_32_64_boinc_tasks_1_0_4.exe'
Error opening "E:\Peli_tmp\magnet:?xt=urn:btih:45739E88FA0032420DEC58FE9010087136803C34\setup_32_64_boinc_tasks_1_0_4.exe.!ut":
Error: setup_32_64_boinc_tasks_1_0_4.exe - El nombre de archivo, el nombre de directorio o la sintaxis de la etiqueta del volumen no son correctos.
translated: name of file, directory name or volume label wording is not correct.
Quote from: Pepo on May 31, 2011, 12:09:07 PM2000/day on all computers.
Approximately, in a rough average: how much active/all tasks do you have and what is their run time? How many tasks are finished daily (or hourly, does not matter)? I assume I'm playing in a diffident league with my 15+10 tasks :)) My system is finishing merely 15-30 tasks daily, thus hard to compare the histories' behavior without knowing its implementation and possible reasons for higher CPU usage.
Quote from: Corsair on May 31, 2011, 01:07:06 PMDepends on the error, I test the magnet on an other computer if it wants to download.
I'm trying the torrent link and after being searching for sometime and when started to download, it gives my one error,
and after that download is stopped and cancelled.
same error when trying TT or BT, client utorrent beta 3.0 beta x64 build 25203
Quote from: fred on May 31, 2011, 01:08:30 PMindeed an other league 8). (I'm feeling irrelevant... :-X) Then I should assume that a) my BT's CPU usage is pretty high ;D, or b) the CPU usage mostly depends on something else but the history refresh time.Quote from: Pepo on May 31, 2011, 12:09:07 PM2000/day on all computers.
Approximately, in a rough average: how much active/all tasks do you have and what is their run time? How many tasks are finished daily (or hourly, does not matter)? I assume I'm playing in a diffident league with my 15+10 tasks :)) My system is finishing merely 15-30 tasks daily, thus hard to compare the histories' behavior without knowing its implementation and possible reasons for higher CPU usage.
18000 in stock, so a pretty good test case.
Quote from: Pepo on May 31, 2011, 01:14:21 PMWhen BT is closed, it only runs the history, and below 1000 the impact should be quite low.
Then I should assume that a) my BT's CPU usage is pretty high ;D, or b) the CPU usage mostly depends on something else but the history refresh time.
Quote from: fred on May 31, 2011, 01:13:10 PMMy uT 3.0b25307 successfully downloaded BT 1.04 some 15 hours ago and has so far seeded 192 kB of it to someones around (possibly to Corsair?) From the previous versions, 1.00 got sent 4.539 times, 1.01 and 1.02 never.Quote from: Corsair on May 31, 2011, 01:07:06 PMDepends on the error, I test the magnet on an other computer if it wants to download.
I'm trying the torrent link and after being searching for sometime and when started to download, it gives my one error, and after that download is stopped and cancelled.
same error when trying TT or BT, client utorrent beta 3.0 beta x64 build 25203
Quote from: Pepo on May 31, 2011, 12:09:07 PMYou forgot your morning coffee again. It's not history refresh time, it's total history log kept.Quote from: Beyond on May 30, 2011, 07:31:12 PMI 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).
...Setting history of 1 or 2 hours kept CPU fairly low. It started increasing dramatically when set to 3 hours or more.
Quote from: fred on May 31, 2011, 06:31:11 AMFred, 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.Quote from: Beyond on May 30, 2011, 07:31:12 PMCan you check this with 1.04, see if there are any improvements.Quote from: Pepo on May 30, 2011, 04:17:05 PMAdditionally, 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.
Quote from: Beyond on May 31, 2011, 03:51:02 PMAh ??? we are talking about different 2 hours, from the same beginning? :-\ :-X :-[Quote from: Pepo on May 31, 2011, 12:09:07 PMYou forgot your morning coffee again. It's not history refresh time, it's total history log kept.Quote from: Beyond on May 30, 2011, 07:31:12 PMI 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).
...Setting history of 1 or 2 hours kept CPU fairly low. It started increasing dramatically when set to 3 hours or more.
QuoteSETI@home 6.10 SETI@home Enhanced (cuda_fermi) 04mr11aa.27560.5384.3.10.174_1 (http://setiathome.berkeley.edu/result.php?resultid=1926981126) 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
Quote6573 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
Quote from: Beyond on May 31, 2011, 03:58:00 PM1 hour 54 minutes CPU in 24 hours with History set to 1 day.
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.
Quote from: Beyond on June 01, 2011, 12:43:04 PMOf course this depends what the time is all about.
1 hour 54 minutes CPU in 24 hours with History set to 1 day.
Quote from: fred on June 01, 2011, 12:44:40 PMAthlon 620 quad. Big improvement, with v1.03 it was 13 hours.Quote from: Beyond on June 01, 2011, 12:43:04 PMOf course this depends what the time is all about.
1 hour 54 minutes CPU in 24 hours with History set to 1 day.
1 hour on a 8 core is something different from 1 hour on a single core.
Quote from: Pepo on May 30, 2011, 08:52:24 PMTo 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!).Quote from: Beyond on May 30, 2011, 07:31:12 PMToday 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.Quote from: Pepo on May 30, 2011, 04:17:05 PM...my history settings were always 365+23.How much CPU time/day are you using with that large a history?
I could tell more after running for a couple of days uninterrupted, or sometimes make a test with a 1 week history buffer.
Quote from: Pepo on June 01, 2011, 05:21:08 PMAfter 3 hours, BT mostly idle except a few minutes at the beginning and now, CPU usage 1:22 minutes 8)Quote from: Pepo on May 30, 2011, 08:52:24 PM... 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...Quote from: Beyond on May 30, 2011, 07:31:12 PMToday 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.Quote from: Pepo on May 30, 2011, 04:17:05 PM...my history settings were always 365+23.How much CPU time/day are you using with that large a history?
I could tell more after running for a couple of days uninterrupted, or sometimes make a test with a 1 week history buffer.
Quote from: Pepo on June 01, 2011, 05:21:08 PM
... 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 |
Quote from: idahofisherman on June 02, 2011, 06:55:00 PMStrange on my computers it shows updating in Projects.
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.
Quote from: Sutaru Tsureku on June 06, 2011, 01:46:24 PMIt may take some time before the menu is available. Initially it's grayed out and becomes active after communicating with the client.
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.
Quote from: fred on June 06, 2011, 04:09:12 PMQuote from: Sutaru Tsureku on June 06, 2011, 01:46:24 PMIt may take some time before the menu is available. Initially it's grayed out and becomes active after communicating with the client.
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.
Quote from: Sutaru Tsureku on June 09, 2011, 02:32:28 PMI will take a look why this takes so long, should be better than 2 minutes.
It may take some time before the menu is available. Initially it's grayed out and becomes active after communicating with the client.
Quote from: Sutaru Tsureku on June 09, 2011, 02:49:40 PMOk I've seen this before, I will add it to the bug list.
Yes, it's the localhost.
After a reboot of the PC.
I start BT, connect to the localhost client.. ~ 2 mins until the menu is clickable.
Quote from: Sutaru Tsureku on June 09, 2011, 02:49:40 PMCan you try File->Exit and than start BT again and see if it happens, probably not.
I start BT, connect to the localhost client.. ~ 2 mins until the menu is clickable.
Quote from: fred on June 09, 2011, 02:54:09 PMFrom my experiences..Quote from: Sutaru Tsureku on June 09, 2011, 02:49:40 PMOk I've seen this before, I will add it to the bug list.
Yes, it's the localhost.
After a reboot of the PC.
I start BT, connect to the localhost client.. ~ 2 mins until the menu is clickable.
But what happens, BT starts first, than the client starts (this may take some time) and it may take a while before the client reports back everything.
Quote from: fred on June 09, 2011, 03:00:53 PMI had all running. Computation/network set to never. Exit BT. (In Windows Task-Manager boinc.exe was shown). BT start and menu immediately clickable.Quote from: Sutaru Tsureku on June 09, 2011, 02:49:40 PMCan you try File->Exit and than start BT again and see if it happens, probably not.
I start BT, connect to the localhost client.. ~ 2 mins until the menu is clickable.