BT 1.04

Started by Pepo, May 30, 2011, 04:17:05 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Pepo

Two issues found, one major:

  • 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?

  • On one computer, my local "history_ComputerName.cvs" files got emptied! All three files (just the running tasks are there), I'm not sure when exactly, but evidently after the upgrade. History files for a not connected remote machine are partially untouched - all contain the historical data.
    Today I had to cold-reset the machine, afterwards with BT 1.03 I could see the most recently logged results from two days ago at the morning - the complete history was there. Later the day (after 15:22 - the download time) I've replaced BT 1.03 with 1.04. When I've checked the History tab, it contained just entries for a remote host.
    After using a 3 weeks old copy of history file, it was accepted, but the initial lines suddenly contain one overlong string in form
1.04
TheMachineNameTheMachineNameTheMachineName............TheMachineNameheMachineNameTheMachineName
BoincTasks History
Project Application Version .......
    where the "machine name" line is 0x07DB2 bytes long!!
    The remote machine's history files - just the "current" got modified this way, the  "machine name" line is "merely" 0x1A0 bytes long! The two older files (cvs1+cvs2) are still dated prior to 15:22 - the installation moment, the current file gets regularly refreshed.[/li]

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.

Regarding Tasks refresh times - on my machine it looks like Fast=2s, Normal=3s, Slow=7s - maybe the Normal time is too tight on the Fast time?
Peter

fred

=<> is cryptic for connected not connected = connecting lost  http://www.efmer.eu/forum_tt/index.php?topic=449.0

I can't reconstruct what happened with the history files, the 3 way setup should be safe.
But when the history isn't read back properly, the others are cleared as well.

But something funny is going on with the computer name, it looks like its added to the old one, causing it to grow.
I don't think it's really used at all, but when it gets that big, something nasty may happen.

The refresh times are highly dependent on the nr of tasks.
I only changed the moment the timer activates and that move to after everything is shown on the screen, this should affect only computers with loooooots of tasks.


Beyond

#2
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.

Pepo

Quote from: Beyond on May 30, 2011, 07:31:12 PM
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.
It 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?

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

fred

Quote from: Beyond on May 30, 2011, 07:31:12 PM
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.
Can you check this with 1.04, see if there are any improvements.

fred

    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]1.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.

    Pepo

    Quote from: fred on May 31, 2011, 06:48:13 AM
    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
    1.04
    TheMachineNameTheMachineNameTheMachineName............TheMachineNameheMachineNameTheMachineName
    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.
    Indeed ;D
    And it grows and grows... :))
    Peter

    Pepo

    Quote from: Pepo on May 30, 2011, 08:52:24 PM
    Quote from: Beyond on May 30, 2011, 07:31:12 PM
    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...
    Today after 5 hours run time (localhost only) the CPU consumption is 22 minutes -> under 2 hours daily. [...]
    I could tell more after running for a couple of days uninterrupted, or sometimes make a test with a 1 week history buffer.
    After 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 PM
    ...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). 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...

    Quote from: Beyond on May 30, 2011, 07:31:12 PM
    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.
    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.
    Peter

    Corsair

    #8
    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 x64 build 25329

    here is the error:

    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.
    Roses don't bloom on the sailor's grave

    Corsair.

    fred

    Quote from: Pepo on May 31, 2011, 12:09:07 PM
    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.
    2000/day on all computers.
    18000 in stock, so a pretty good test case.

    fred

    Quote from: Corsair on May 31, 2011, 01:07:06 PM
    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
    Depends on the error, I test the magnet on an other computer if it wants to download.

    Pepo

    Quote from: fred on May 31, 2011, 01:08:30 PM
    Quote from: Pepo on May 31, 2011, 12:09:07 PM
    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.
    2000/day on all computers.
    18000 in stock, so a pretty good test case.
    indeed 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.
    Peter

    fred

    Quote from: Pepo on May 31, 2011, 01:14:21 PM
    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.
    When BT is closed, it only runs the history, and below 1000 the impact should be quite low.

    Pepo

    Quote from: fred on May 31, 2011, 01:13:10 PM
    Quote from: Corsair on May 31, 2011, 01:07:06 PM
    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
    Depends on the error, I test the magnet on an other computer if it wants to download.
    My 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.
    Peter

    Beyond

    Quote from: Pepo on May 31, 2011, 12:09:07 PM
    Quote from: Beyond on May 30, 2011, 07:31:12 PM
    ...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.