This is not only for this version is from previous too.
Tasks Tab - Running High Priority - both of them per CPU and GPU shown with same colour,
this sometimes could give the impression in a quick view that one WU is running on CPU instead
of GPU (just as I told you in a quick view, as "Plan_Class" is shown after the name we could
discriminate which one is)
should be fine to have another colour for the GPU tasks in high priority.
Quote from: Corsair on December 09, 2010, 03:52:39 PM
should be fine to have another colour for the GPU tasks in high priority.
On the list, for some reason it was never requested.
Quote from: fred on December 09, 2010, 04:26:16 PM
Quote from: Corsair on December 09, 2010, 03:52:39 PM
should be fine to have another colour for the GPU tasks in high priority.
On the list, for some reason it was never requested.
I think because is rare to see it, just if rescheduling task from CPU --> GPU,
because don't like work on CPU on such project and GPU gets stuck of job ??
what I really don't know is what happens with one of my computers that only
takes job for SETI CPU instead of GPU, and it's well defined in the .xml file
(installed with Lunatics 0.37 x64 with no installation of AP), and after rescheduling
you could see smoothly run the WU with "cuda_fermi", but as told you is really
strange that this computer downloads work nearly only for CPU.(without rescheduling)
Quote from: Corsair on December 09, 2010, 05:46:40 PM
what I really don't know is what happens with one of my computers that only
takes job for SETI CPU instead of GPU, and it's well defined in the .xml file
(installed with Lunatics 0.37 x64 with no installation of AP), and after rescheduling
you could see smoothly run the WU with "cuda_fermi", but as told you is really
strange that this computer downloads work nearly only for CPU.(without rescheduling)
Check if he asks for GPU work . But if work is asked for the GPU and you get an occasional one, everything is fine.
Check the GPU debt with other projects, you could set it to 0.
The tooltip for cropped overlong Messages' lines is tooooo short.
Quote from: Pepo on December 09, 2010, 06:39:29 PM
The tooltip for cropped overlong Messages' lines is tooooo short.
Doesn't Windows impose a maximum character length on tooltips ???
Quote from: jjwhalen on December 09, 2010, 07:45:12 PM
Quote from: Pepo on December 09, 2010, 06:39:29 PM
The tooltip for cropped overlong Messages' lines is tooooo short.
Doesn't Windows impose a maximum character length on tooltips ???
Yes and no, default is 80, but it is possible to make it longer.
But who makes such long translations. ;D
Quote from: fred on December 09, 2010, 08:29:45 PM
Quote from: Pepo on December 09, 2010, 06:39:29 PM
The tooltip for cropped overlong Messages' lines is tooooo short.
But who makes such long translations. ;D
Ask e.g. the rosetta@home team - BT is not capable of displaying their task names in an uncropped tooltip
;D which is actually not that long compared to the screen size (I can often see tooltips in Visual Studio spanning 2 widescreens), just that my task name column is usually shrunk to just a bit more than some 12 characters, to accomodate for the number of filtered tasks + a bit more.
Happens in
both Tasks, Transfers and History tabs.
Luxrenderfarm@home is showing 139.298% completed with no time left to finish and is still actively running. :o
Quote from: Pepo on December 09, 2010, 10:21:26 PM
Ask e.g. the rosetta@home team - BT is not capable of displaying their task names in an uncropped tooltip ;D which is actually not that long compared to the screen size (I can often see tooltips in Visual Studio spanning 2 widescreens), just that my task name column is usually shrunk to just a bit more than some 12 characters, to accomodate for the number of filtered tasks + a bit more.
Happens in both Tasks, Transfers and History tabs.
Added to the list, shouldn't be too hard to do.
After a restart from thread timeout, selection bar goes under toolbar operation. It seems it can't remember where it was.
before restart:
(http://ploader.net/files/b9101b3bcda640ee7bc403bdec96f92c.PNG)
after restart:
(http://ploader.net/files/2d8f00dc3b4b7fe51e8743e0e5c1a694.PNG)
Quote from: glennaxl on December 10, 2010, 08:56:33 AM
After a restart from thread timeout, selection bar goes under toolbar operation. It seems it can't remember where it was.
The bars are stored when BT exits normally.
Did BT crash (crash report)?
Quote from: idahofisherman on December 10, 2010, 02:07:41 AM
Luxrenderfarm@home is showing 139.298% completed [...] and is still actively running. :o
I'm glad that BT is not clipping the Progress% to 100.00000 and shows the true reported value. BOINC Manager is unfortunately hiding such application bugs, none will then notice and complain.
BTW, would BT correctly display a negative Progress%?
Quote from: idahofisherman on December 10, 2010, 02:07:41 AM
... 139.298% completed with no time left to finish and is still actively running...
This bug was just repaired in trunk, changeset [22834] (http://boinc.berkeley.edu/trac/changeset/22834).
Quote from: fred on December 10, 2010, 11:23:54 AM
Quote from: glennaxl on December 10, 2010, 08:56:33 AM
After a restart from thread timeout, selection bar goes under toolbar operation. It seems it can't remember where it was.
The bars are stored when BT exits normally.
Did BT crash (crash report)?
I don't think it crashed as there's no dump file generated for today. It always happen even on previous versions (cant remember whc way back).
One thing for sure that I will get this issue is when one of my host (remote - from far far away land :) ) goes offline then BT will have a thread timeout - results to toolbars in the wrong place.
Quote from: glennaxl on December 10, 2010, 04:55:56 PM
I don't think it crashed as there's no dump file generated for today. It always happen even on previous versions (cant remember whc way back).
One thing for sure that I will get this issue is when one of my host (remote - from far far away land :) ) goes offline then BT will have a thread timeout - results to toolbars in the wrong place.
I made a note to test it.
Quote from: fred on December 10, 2010, 04:59:45 PM
Quote from: glennaxl on December 10, 2010, 04:55:56 PM
I don't think it crashed as there's no dump file generated for today. It always happen even on previous versions (cant remember whc way back).
One thing for sure that I will get this issue is when one of my host (remote - from far far away land :) ) goes offline then BT will have a thread timeout - results to toolbars in the wrong place.
I made a note to test it.
I was unable to reproduce glenaxl's symptom by either killing BT externally from Process Explorer, or internally using the silver bullet. The selection bar stayed where it was placed, next to the operation bar.
So that "thread timeout" situation may be unique. I don't have any remotes further than the next room, all on the same subnet, so can't really reproduce glenaxl's conditions.
from previous version, I've had one crash that doesn't leave anything, and something like:
a farm of computer.
by means of testing one of then w7-pro-x64 & BTx64, laptop wxp-pro-x32 & BTx32.
when one of this computers is rebooted or started BT in the other computer just quit without producing any error, neither crash file, etc.
I'm watching in this version and for the moment hasn't being, I'll keep an eye on it if happens again.
Quote from: Corsair on December 10, 2010, 07:38:05 PM
from previous version, I've had one crash that doesn't leave anything, and something like:
a farm of computer.
by means of testing one of then w7-pro-x64 & BTx64, laptop wxp-pro-x32 & BTx32.
when one of this computers is rebooted or started BT in the other computer just quit without producing any error, neither crash file, etc.
I'm watching in this version and for the moment hasn't being, I'll keep an eye on it if happens again.
This version should have eliminate a couple of bug in the reconnect, as well as a bug when the connection breaks of unexpectedly.
Quote from: glennaxl on December 10, 2010, 08:56:33 AM
After a restart from thread timeout, selection bar goes under toolbar operation. It seems it can't remember where it was.
I tested it, but can't reproduce that effect.
Later versions of BT (not sure exactly when it started) have been using a LOT more CPU time than previous versions. Is feature creep the cause?
Quote from: Beyond on December 12, 2010, 11:19:08 PM
Later versions of BT (not sure exactly when it started) have been using a LOT more CPU time than previous versions. Is feature creep the cause?
Depends on what a LOT is an when is when. Of course every new thing has to come from somewhere. But I normally take that in consideration. Some changes have done the opposite, so I don't think there is more overhead on the latest version.
BT should be hidden when not in use. In this state it uses a lot less resources than shown.
A couple of 1000 WU's in tasks will help. Setting the refresh rate to a longer time will help.
A large history will help. Try to keep the history at 1 day, on a system with thousands of WU's.
Quote from: fred on December 12, 2010, 02:04:26 PM
Quote from: glennaxl on December 10, 2010, 08:56:33 AM
After a restart from thread timeout, selection bar goes under toolbar operation. It seems it can't remember where it was.
I tested it, but can't reproduce that effect.
I can't either but it happens to me from time to time. I'll note it next time when it occur.