Messages

I'm running BOINC 6.12.6α on all hosts.

I haven't seen any BT crashes with v0.89 as reported by Beyond & Corsair.  Instead BT is repeatedly dropping/reconnecting one of my remote hosts every few seconds, while remaining connected to localhost & the other remote.  Restarting BT & rebooting localhost had no effect.  No crashes, so no .dmp files.  No unusual activity seen in the BT log in debug mode.

Unlike v0.88, the random number in the Projects tab's Tasks field is now appearing in (most but not all) cells where the task count is nonzero.

I'll be reverting to v0.88β.

Regarding "Set debt":

I agree with Beyond that this is a useful addition.  A few points...

1) Projects>Set debt only works if "All computers" is selected & a project is highlighted.  If a single computer is selected the menu item is active (not grayed out) but does nothing.  Either (in descending order of desirability)
    a) Let it call the dialog for that computer, or
    b) Make it inactive when a single computer is selected.

2) If the dialog is opened, a project is selected, the data entry fields are left blank, and "Apply" is clicked, this causes debts to be zeroed out for that project.  It is very easy to accidentally zero debts that you don't want/can't afford to.  Nulls in the data entry fields should not be read in as zeros, and hitting Apply on null fields should result in either no action or an error message.  To zero debts, the user should have to deliberately enter "0" "0.0" or some permutation into the data entry field(s) and then click "Apply".

3) Numbers entered into the data entry fields stay there, even after the dialog is closed, until BT is restarted.  Data entry fields should be cleared whenever
    a) Apply is clicked,
    b) A different project is highlighted on the selection list, or
    c) The dialog is closed.

Feature request: request the Set debt menu item be added to the Context Menu of the Projects tab, with the same functionality as Projects>Set debt.

Question: will you be adding capability to adjust GPU debts at a later date?

Fred,

Back around v0.56 or so we got a Status "Aborted by project" implemented in Tasks & History, to differentiate from a user abort.  Yoyo, for one, uses project abort a lot to keep the server workload down.

That change is still displaying on the History tab, but Tasks has gone back to just plain Status "Aborted" for a project abort.  Did you maybe go back to an earlier version of the code in that area?

You can switch off the filter for aborted.
Fixed a bug in V 0.89 to show the real status on 1 filtered task.

Great; I guess it never occurred to me that the filter acts on just a single line entry that matches the filter criteria -- but why not.

But this raises a new question: if the filter option "Aborted" is checked and the computer has multiple aborts, some user and some project, does this mean that the filter will combine them all into a single line entry?  I would expect "Aborted by project" to be treated as a completely different Status and not touched by filter criterion "Aborted"  I may user-abort 100+ tasks and want them to be filtered.  But project aborts are relatively rare and I want them to stand out

Fred,

Back around v0.56 or so we got a Status "Aborted by project" implemented in Tasks & History, to differentiate from a user abort.  Yoyo, for one, uses project abort a lot to keep the server workload down.

That change is still displaying on the History tab, but Tasks has gone back to just plain Status "Aborted" for a project abort.  Did you maybe go back to an earlier version of the code in that area?

The huge random number appears if and only if the first 2 values are 0/0, which is the case for your DNETC (mine too).  Any project with no work will show a huge random number
The nci issue that we're talking about is different and doesn't show the huge number in field 3.

Thanks for the clarification, Beyond.  The point I was trying to make is that after updating to BT 0.88, DNETC correctly read "0/0/0" until the FreeHAL task on that host was aborted bringing its count to 0/0/0, after which both projects displayed the random number.  This is the strange behavior I was talking about, related to your NCI issue or otherwise.

Best wishes.

As the number of projects on a computer rises, the width of the widest bars in "Share %" column, which symbolize the single projects' Resource Share, effectively approaches zero pixels. The narrow ones were indefinitely thin already a long ago...

If some new optional mode would be introduced to size them not absolutely to the 0-100% width, but to maximize the widest one and the narrower ones (on the same computer) relatively to it, the functionality might be again useful even with larger number of projects. (I understand that the bar width would be not comparable across computers anymore, but therefore 'optional'.)

Someone who is supporting this.

Personally, I don't find the color bars here that useful anyway (unlike CPU% and Progress%).  Since I've always supported multiple projects, I've always preferred to look at the numbers directly for Resource Share.

Sorry, Peter.

Strangely, I am getting the "huge random number" on DNETC@HOME, which
a) is a Reserve Project (resource share 0) with no work onboard, and
b) does NOT do NCI in any case.
DNETC currently reads "0/0/1 769 105 279", which only appeared after I aborted a FreeHAL task, bringing its count to 0/0/0.

Also on the same machine (a quad/GPU), FreeHAL currently reads "0/0/1" even though there are 2 NCI WUs onboard & processing (one per two cores selected at the FreeHAL server).

As Fred says, should be an easy fix

• tab "Tasks" column "Temperature" empty, no reading of any kind of any computer

No temps at all here either.

I also had no temps on the tasks display for any computer.  This makes v0.85 DOA for me  & I've reverted to v0.84 pending a fix for that.

Minor bug:

While checking the implementation of

Fixed: Task Properties doesn't show elapsed and CPU time, when a task is completed,

which appears to be working fine, I noticed that "Fraction done" in Task Properties for a completed task reads 0.000%.  It may have been that way since the task property sheet was implemented, and I just never noticed before.  Fraction done for tasks in progress appears to be tracking OK.

Not exactly the end of the world, but...

FreeHAL's new nci release 1.83 apparently has a fix for the weird progress indications at the start of a task, as described earlier in this thread by Pepo.  There's been some talk about it over on their user forum.  They were down most of yesterday, obviously implementing the changes.

At least the first 1.83 tasks I received this morning (California time) all showed a "normal" progress progression from startup.  Cautious optimism.

Interesting is that this slowed state persists just as long as the BTs are connected to the particular client.

Maybe I've got it? I've just seen that the History tab's status bar constantly displays  "Updating..." without the usual 30 second countdown. I've seen something like this in the past when observing a task approaching its finish. A look into the Tasks tab: One FreeHal@home pseudo-nCi task was claiming being progressed to some couple of hundreds or thousands %...
I've aborted the task, updated project - as the task disappeared, BT was suddenly working as usual.. After downloading a new FreeHal@home task and starting it, in a while (around 141.756% seems to be enough) BT was sluggish again
Suspending the task seems to be enough to heal the sluggishness.

So, the idea was that maybe the high progress percentage triggers BT to go into "superfast history fetching" mode for a task approaching its end? The task contains sometimes no ETA, or "Estimated time remaining      -", sometimes just a few seconds...

BTW, what about displaying the weird progress percentage? BOINC Manager displays no (0.000%) Fraction done for the task, the same is true for BT's task properties window. But the Tasks tab often displays a strange value. Is it somehow computed? I suspect that the strange application generates no fraction_done, among other things it also generates no boinc_task_state.xml file in its slot...

I can confirm Pepo's observations (good catch, Peter!).  Newly downloaded FreeHAL WUs in (let's call it startup mode for want of a better term) appear to be gumming up the works.  The impossibly high Progress % seems to persist until the task reaches its first checkpoint, then changes to a credible 0.nnn% and increments at a believable rate.  Suspending project or disconnecting the affected computer appear to restore BT's normal update frequency immediately. 

I recall some discussion in this forum a few months ago about BT's algorithm for Progress %, but don't remember the details.  It looks like FreeHAL's "unique" way of doing business isn't appreciated by that process.  I also noticed that after aborting a FreeHAL task the displayed State changes to Aborted, but Progress % continues to increment for some time, possibly the rest of the current checkpoint interval, after which it changes to 100.000%.  Whether the task is actually still running after an abort command I don't know, but I wouldn't be surprised.

[51,639.81 172,210.50]

...it may be a matter of taste.

...which is off course true.

Is there somebody else with an opinion?

I'll weigh in on this: I'm with Pepo - the indicated (CPU time) of multicore/multithreaded tasks should preferably show the aggregate of all cores summed together, as was done in earlier versions of BT.  If for no other reason, then to be consistent with the results that appear in AQUA's database, e.g.,

9 Oct 2010 10:22:07 UTC   12 Oct 2010 1:24:19 UTC   Completed and validated   51,639.81   172,210.50   13,577.28   D-Wave's Iterative QUANtum Algorithms : Multi-Threaded v1.14 (mt1)

Minor glitch: the Update dialog is currently showing

Current version: 0.77  ( Latest version : 0.74 , (Latest beta version : 0.76) )

So when you get around to compiling 0.78. . .

Is there anyone who has problems aborting tasks?

I've never had any problem with Abort Tasks or Transfers.  The longer the list being aborted, the longer process takes.  But I consider that normal behavior, not a problem.

I recently attached FreeHAL (groan), & yes I know that project does things a bit strangely.  And I've reviewed past forum postings with keyword "FreeHAL".  But do we know why, with a task in progress on each host, on the Projects tab the Tasks count remains at "0/0" and the Time Left at "-/-"?  Something to do with the use/resource value being <1CPU?