Seti is down again

[Miep]

BTW, on my good old Athlon 64 I have 3 SETI MB tasks in download state now ... and absolutely idle CPU
Einstein backup refuse to ask for work. BOINC thinks that SETI tasks should be run instead (but they not downloaded and will not be downloaded any time soon).
Obviously it's BOINC bug. Anyone knows is it fixed already and in what BOINC version?

If you haven't any SETI left, you could try suspending it altogether from the projects tab. Else suspending the no yet downloaded tasks from the tasks tab should work.

[Richard Haselgrove]

BTW, on my good old Athlon 64 I have 3 SETI MB tasks in download state now ... and absolutely idle CPU
Einstein backup refuse to ask for work. BOINC thinks that SETI tasks should be run instead (but they not downloaded and will not be downloaded any time soon).
Obviously it's BOINC bug. Anyone knows is it fixed already and in what BOINC version?

I reported it in early July, and David fixed it the same day - http://boinc.berkeley.edu/trac/changeset/21877

But unfortunately that was too late for any of the BOINC v6.10.xx line - the last (.58) was released five days earlier.

It should be in all the v6.11/12 test builds: v6.12.4 (yesterday) should have non-FIFO GPU scheduling too - but I need a second viabale CUDA project (apart from GPUGrid) to test that.

And as Carola says, suspending the individual SETI tasks that can't download released the logjam for me.

[Jason G]

That's a good one line fix.  I like those those kind  .  Any more I should look for ?

[Raistmer]

hehe, yesss
I look at this PC queue good if once per month or rare now, too busy with GPU-enabled once
And her 3 not coming tasks definetely was that killed the Pappa's Camel

[Raistmer]

BTW, on my good old Athlon 64 I have 3 SETI MB tasks in download state now ... and absolutely idle CPU
Einstein backup refuse to ask for work. BOINC thinks that SETI tasks should be run instead (but they not downloaded and will not be downloaded any time soon).
Obviously it's BOINC bug. Anyone knows is it fixed already and in what BOINC version?

If you haven't any SETI left, you could try suspending it altogether from the projects tab. Else suspending the no yet downloaded tasks from the tasks tab should work.

Yes, I did so. But this required manual intervention. And as I said already I look into that host only once per month...

[Claggy]

That's a good one line fix.  I like those those kind  .  Any more I should look for ?

How about this one: http://boinc.berkeley.edu/trac/changeset/22206

It's a response to a problem i reported in early August, and is incorporated in the 6.11 and 6.12 series,

Claggy

[Jason G]

LoL, that's a pretty bad one actually.  Will see what I can do for Mod12.  [Edit:] Yes, reading it I remember that one now, I'll  include that fix also.
[Done]

[perryjay]

Looks like we are on our way again.

[cristipurdel]

Did they managed to fix the FIFO bug for GPUs in 6.12.x?

[Claggy]

Did they managed to fix the FIFO bug for GPUs in 6.12.x?

Yep, 6.12.4 has this fix:

•client: use project STD, rather than arrival time,
as the major criterion in choosing non-EDF GPU jobs.
GPU scheduling now respects resource share,
and as a result STD should no longer diverge.

I'm running 6.12.4 on my T8100 Laptop, but since it can only run one Cuda project, can't tell if it's fixed.

Claggy

[Richard Haselgrove]

I'm running 6.12.4 on my T8100 Laptop, but since it can only run one Cuda project, can't tell if it's fixed.

I've loaded v6.12.4 on my Fermi, and zeroed debts on the way in so everything starts level.

The good news: yes, task startup by debt is working. Starting from zero, it finished off the SETI task in progress, building up a small amount of debt. When that finished, it pulled a GPUGrid task from well down the page, and started that next.

The bad news: it's overly agressive on task switching. 8 minutes later (triggered by a SETI work allocation), it preempted the GPUGrid task, and started running SETI again. Later on, it preempted SETI, and went back to GPUGrid.

And I'm still getting 'leakage' into CPU STD for projects which should be ineligible.

So, test with caution: this isn't the end of the story. Credit hounds may wish to avoid this version - all that task switchinbg, especially given the heavy SETI start-up penalty, isn't going to be efficient.

[msattler]

I'm running 6.12.4 on my T8100 Laptop, but since it can only run one Cuda project, can't tell if it's fixed.

I've loaded v6.12.4 on my Fermi, and zeroed debts on the way in so everything starts level.

The good news: yes, task startup by debt is working. Starting from zero, it finished off the SETI task in progress, building up a small amount of debt. When that finished, it pulled a GPUGrid task from well down the page, and started that next.

The bad news: it's overly agressive on task switching. 8 minutes later (triggered by a SETI work allocation), it preempted the GPUGrid task, and started running SETI again. Later on, it preempted SETI, and went back to GPUGrid.

And I'm still getting 'leakage' into CPU STD for projects which should be ineligible.

So, test with caution: this isn't the end of the story. Credit hounds may wish to avoid this version - all that task switchinbg, especially given the heavy SETI start-up penalty, isn't going to be efficient.

I thought the task switching rate was a user configurable option.......switch between tasks every......
Does that not work here?

[Raistmer]

The bad news: it's overly agressive on task switching. 8 minutes later (triggered by a SETI work allocation), it preempted the GPUGrid task, and started running SETI again. Later on, it preempted SETI, and went back to GPUGrid.

And I'm still getting 'leakage' into CPU STD for projects which should be ineligible.

So, test with caution: this isn't the end of the story. Credit hounds may wish to avoid this version - all that task switchinbg, especially given the heavy SETI start-up penalty, isn't going to be efficient.

IMO not only "credit hounds" but all who take care about their host performance. GPU task switching should be at minimum even stronger than CPU task switching (any task switching is bad enough, but GPU is just worst).
Interesting, will this version do preemting of MW GPU tasks that don't checkpoint at all ?
I've seen foolish pre-emting of 3min-only ATI MW tasks in prev builds (for example, when another GPU task from another project un-suspended and BOINC decides to continue it immediately (and no, no high priority mode and far-far from deadline) ).
Very nature of GPU apps implies much bigger startup overhead, for different projects this overhead will be different of course, but in all cases it will be much bigger than corresponding CPU overhead. So switching GPU task in progress w/o absolute need is counterproductive.

[Raistmer]

I thought the task switching rate was a user configurable option.......switch between tasks every......
Does that not work here?

LoL, it works ~ in same extent as user-configurable project shares in all prev builds before "backup project" was implemented properly. In short, it almost doesn't work.

[
BTW, if BOINC would respect user settings more and switch to another task only after user-specified number of minutes (if no high-priority mode involved) it could complete GPU task and do switch on task boundary cause most GPU tasks (maybe except GPU grid with their long GPU tasks) will finish earlier than even default of 60 min.
]

[Richard Haselgrove]

Agree totally with you both - but this is an early, TEST build. I'll be filing a bug report, of course, with logs.

But I've no experience with MilkyWay - I'm not attached. Someone else had better do that one.

Let's see if we can get the bugs out of this one before they move on to the v6.13.xx line