I currently see a problem in the work fetch part of the scheduler. I've been trying for several days to figure out how to describe it in enough detail, and have enough solid examples, that the developer will instantly agree with me - if I fall short, I'll lose credibility, and it'll be harder to "prove" that there's really a problem that needs to be fixed; my argument has to be as perfect as I can make it before I send it in.

*whimper* Meanwhile, as I'm still mentally arguing the issue from both sides, and after writing (but not posting) a bazillion words on it, he strolls through and sees the thread where I'm trying ineffectually to explain what's happening to the user, (who is looking at the CODE!), and says basically "Yep. That's broke all right. I should fix it." and strolls off again...

They DO listen!

---

*whimper* Meanwhile, as I'm still mentally arguing the issue from both sides, and after writing (but not posting) a bazillion words on it, he strolls through and sees the thread where I'm trying ineffectually to explain what's happening to the user, (who is looking at the CODE!), and says basically "Yep. That's broke all right. I should fix it." and strolls off again...

They DO listen!

Yes they do ...

Where was this? There has to be more to this story...

---

Connect to network about every
(determines size of work cache; maximum 10 days)

The 2nd line must have been added within the past 6 months or so, because it wasn't there the last time I had a need to change my general preferences.

Thx.

(Which I have been pushing to drop the first sentence and only leave the second...)

Good idea.

I'm just saying that we've "been there, done that, it didn't work".

I sincerely appreciate your effort to try and explain the scheduler, but as you have already admitted, you've written a bazillion words and still can't adequately explain it. Conclusion: it's too complicated.

Like I've said, I have already "fixed" the scheduler for MY 7 machines. I have only ONE project running on EACH machine. SIMPLE can be good you know. [grin]

The simpler scheduling was abandoned ... when people were missing too many deadlines.

And people were complaining about missed deadlines because ... ?
... the science was affected -OR-
... they weren't getting their credits ? (hint: it's this one)
(and someone complained about ME not being there for the projects !?!)

--- bt

bt,

I'll now try to contribute something of substance to this discussion.

...I sincerely appreciate your effort to try and explain the scheduler, but as you have already admitted, you've written a bazillion words and still can't adequately explain it. Conclusion: it's too complicated.

Complicated, YES. It's some of the most sorted-out coding in Boinc, and probably the most intricate. ANY changes to it, even the most subtle, are likely to have a "cascade effect" which then becomes a nightmare to get right again. They are understandably extremely reluctant to change something that is considered to be working fine by most.

Like I've said, I have already "fixed" the scheduler for MY 7 machines. I have only ONE project running on EACH machine. SIMPLE can be good you know. [grin]

Yes, you have applied an elegantly simple solution, that works fine up to a point. If you don't mind having one or two of your machines being in a non-contributing state when a project or two goes off-line (I'm sure you know well that this is a frequent occurance), or if you don't mind re-assigning that machine or two to another project in the interim, then it is an entirely satisfactory solution for you.

And people were complaining about missed deadlines because ... ?
... the science was affected -OR-
... they weren't getting their credits ? (hint: it's this one)
(and someone complained about ME not being there for the projects !?!)

OK, let's keep it real here. :-)
If it were not for the credit and the eye-candy screensaver, how much participation do you think these research projects would have, compared to the present? I'd guesstimate they could probably count upon maybe 20-25%, and I wouldn't be surprised to find that figure to be optimistic. They just can't completely rely upon the few people of purely altruistic purpose.

---

"The arc of history is long, but it bends toward Justice"

They are understandably extremely reluctant to change something that is considered to be working fine by most.

I completely agree with you. I wouldn't either. But one size doesn't necessarily fit all. I suggest that they offer two options: a simple time slicing option; and the current "complicated" system. That way I have a choice.

I think most people don't even notice or care. I only noticed because I spotted the fact that CP.NET had not run on my laptop for over 4 days. In fact only 3 of my 7 projects had any WU's sitting on my machine, even though 3 of the other 4 projects were up and dishing out WU's.

It just seemed entirely counter-intuitive that BOINC didn't have at least one WU from each project and that two projects had completely hijacked my machine. And to make matters worse, BOINC was allowing this to happen !!

If you don't mind having one or two of your machines being in a non-contributing state when a project or two goes off-line

I completely agree with you, but this is a calculated risk that I'm prepared to accept. I'll set the cache to 10 days. That should help. When I was running the classic SETI I used SETI-QUEUE with a 7 day cache. It worked GREAT !!

What I will do is switch them all around every week or so - with the exception of CP.NET becuase it takes months to run one WU. CP.NET is one of those projects that is best to run on a dedicated machine anyway.

If it were not for the credit and the eye-candy screensaver, how much participation do you think these research projects would have. They just can't completely rely upon the few people of purely altruistic purpose.

Agreed. I couldn't care less about the screensaver. And I use the credits to track how my machines are performing. Although I really don't think it's a very good measure, espeically in light of the scheduler issues ... but let's not go there. grin

--- bt