It's human nature, when things are running along smoothly and there is a sudden observed change, to assume the worst....LOL.

Humans are very habitual creatures. We assume the worst to brace ourselves and our fears, but it doesn't have to be that way. We can actually train ourselves to think rationally and logically in any situation instead of making assumptions and grabbing pieces of data to draw invalid conclusions.

I see this happen all too often, and it has even happened to me very recently. It's never appreciated when it happens to you, so we should try not to do it to others, IMHO.

---

But it's all good to sanely discuss it.....

The technical discussion is always good.

... and as a technical project, policy changes (if that's what it is) are generally driven by technical requirements.

If it was done intentionally, there is usually a good reason. It may not make everyone happy, and we may disagree with it. It may even get reversed when it proves to have been a bad idea.

What isn't good is when someone "shoots from the hip" -- when they immediately blame the project for "doing something to the crunchers" -- and then turn around and then say that they quit before because of what the project "did to them."

I don't think that's appropriate. In virtually every case, it turns out to be an error, either on the part of the project, or on the part of the person complaining.

Before we hang the project management in effigy, we should find out what happened.

Ned, thank you for responding to my post. Before I'm tagged with "shooting from the hip" or "hang(ing) the project management in effigy", please understand what I'm asking for (which I've done a poor job articulating).

1) better communication up-front. We're a community and if we should trust our community enough to explain the difficulties/challenges we face, and policies/decisions choices to respond to observed bugs we're encountering, we're really not leveraging on the collective abilities of the community.

Since (I assume -- guessing without data) we share the same objective of wanting to help, will you agree that to discover what's happening, it's easier (more effective given the limited number of human resources, I read 3 resources somewhere?) if those in the know communicate up-front, allowing the community opportunities to respond. I'm hoping 'facts promptly available + more brains = better decisions if not better solutions'.

2) I agree with you that frustration overcame my better judgment in stating my (sample size of one person) decision some years back. What you didn't (and couldn't have known) was the emails inquiries I sent (written sans emotions) that were never responded to…but I digress and it's ancient history anyways. Still no excuse for voicing a past choice which has no relevance whatsoever to the issue at hand. 'Shooting from the hip', guilty as charged. 8)

For the record, I never wrote nor infer to hang the project management in effigy. If I don't believe in SETI, I wouldn't have returned given the opportunity and time.

My poorly-articulated email was written with the hope of gaining more clarity on the issue. To everyone offended by my post, my sincerest apology.

---

Whatever changes have happened were unintentional. There were no policy changes that I am aware of. What probably happened is that a "bug" was fixed in BOINC that led to a configuration parameter that was previously ignored being enforced. There have been a lot of changes to the BOINC scheduler recently. I'll inform David of the difference.

That said, there may come a point in time when the demand for work exceeds our network bandwidth or the rate at which data comes from the telescope. (It's certainly not that way today judging from the network graphs.) At that point we would have to decided whether to limit work so that everyone has a chance to get some. At that point, which is worse, a "No work available from project" message or a "daily quota exceeded" message? Which is more important, ensuring everyone can participate, or making sure the fastest machines that have signed up are fully employed? It's a decision we haven't had to make yet, but one we will probably need to make at some point. And regardless of how the question is decided, some people will be angry.

---

@SETIEric@qoto.org (Mastodon)

Whatever changes have happened were unintentional. There were no policy changes that I am aware of. What probably happened is that a "bug" was fixed in BOINC that led to a configuration parameter that was previously ignored being enforced. There have been a lot of changes to the BOINC scheduler recently. I'll inform David of the difference.

Eric (and all the other posters),

Thanks for your responses. As has been said elsewhere, it's far from the end of the world, but certainly is outside of past experience and unexpected. So I'm glad I pointed it out, and will look forward to additonal information as it becomes available. FWIW, I checked the BOINC dev forums and there is no mention of this or anything similar as of 00:00 GMT.

That said, there may come a point in time when the demand for work exceeds our network bandwidth or the rate at which data comes from the telescope. (It's certainly not that way today judging from the network graphs.) At that point we would have to decided whether to limit work so that everyone has a chance to get some. At that point, which is worse, a "No work available from project" message or a "daily quota exceeded" message? Which is more important, ensuring everyone can participate, or making sure the fastest machines that have signed up are fully employed? It's a decision we haven't had to make yet, but one we will probably need to make at some point. And regardless of how the question is decided, some people will be angry.

This probably could be a whole new thread, but here's my thought:

I have been running five systems exclusively allocated to SETI for various portions of each day, up to and including 24/7. Several of these systems are clearly older technology (read: old and inefficient), so I've started decommissioning them. The plan is to replace three older boxes (5 CPU cores) with one new box (Core i7 and 3 GPU cards). 200 units per day on such a box would hardly warm it up. Unless, of course, a good number of the 200 are AP.

BUT: That's why there are other projects. If the powers decree that each system has a max 200 WU/day limit at SETI, I'll add more projects to pick up the slack. I'd rather get 200 a day than a day's worth of "no work available" messages. Your mileage, of course, may vary.

Don't know about the quota....but something sure has changed with the server/scheduler....
The Frozen Nehi, which trashed it's cache last night and had to start from scratch, was on deferred comms all day after getting it's limit last night.

It just hit server midnight, and the first work request it did received 58 WUs....as compared to the usual 20 WU per request in the past.
The second request got 57, the 3rd request got another 56...
The it made a number of requests that only got a few WUs...I think Boinc has filled the cache.

---

"Freedom is just Chaos, with better lighting." Alan Dean Foster

I let run BOINC V6.4.7 and had before the weekly maintenance 500WUs/GPU -> 2,000 for the whole GPU cruncher.

After the weekly maintenance I have - I guess - again 100WUs/CPU enabled.. (server side)..
Because I get now only 400 WUs/day for my GPU cruncher.


My GPU cruncher make ~ 580 AR 0.44x WUs/day.

Now I'm angry, because I can't get enough WUs for 24/7 crunching..


If you count in the killed VLARs and shorties.. maybe soon he will crunch only 12/3.5 .. but he's online 24/7..

---

Whatever changes have happened were unintentional. There were no policy changes that I am aware of. What probably happened is that a "bug" was fixed in BOINC that led to a configuration parameter that was previously ignored being enforced. There have been a lot of changes to the BOINC scheduler recently. I'll inform David of the difference.

That said, there may come a point in time when the demand for work exceeds our network bandwidth or the rate at which data comes from the telescope. (It's certainly not that way today judging from the network graphs.) At that point we would have to decided whether to limit work so that everyone has a chance to get some. At that point, which is worse, a "No work available from project" message or a "daily quota exceeded" message? Which is more important, ensuring everyone can participate, or making sure the fastest machines that have signed up are fully employed? It's a decision we haven't had to make yet, but one we will probably need to make at some point. And regardless of how the question is decided, some people will be angry.

MB GPU work is quite different than AP CPU work. Quotas regarding MB and AP should be counted separately.

---

me@rescam.org

But it's all good to sanely discuss it.....

The technical discussion is always good.

... and as a technical project, policy changes (if that's what it is) are generally driven by technical requirements.

If it was done intentionally, there is usually a good reason. It may not make everyone happy, and we may disagree with it. It may even get reversed when it proves to have been a bad idea.

What isn't good is when someone "shoots from the hip" -- when they immediately blame the project for "doing something to the crunchers" -- and then turn around and then say that they quit before because of what the project "did to them."

I don't think that's appropriate. In virtually every case, it turns out to be an error, either on the part of the project, or on the part of the person complaining.

Before we hang the project management in effigy, we should find out what happened.

Ned, thank you for responding to my post. Before I'm tagged with "shooting from the hip" or "hang(ing) the project management in effigy", please understand what I'm asking for (which I've done a poor job articulating).

1) better communication up-front. We're a community and if we should trust our community enough to explain the difficulties/challenges we face, and policies/decisions choices to respond to observed bugs we're encountering, we're really not leveraging on the collective abilities of the community.

Since (I assume -- guessing without data) we share the same objective of wanting to help, will you agree that to discover what's happening, it's easier (more effective given the limited number of human resources, I read 3 resources somewhere?) if those in the know communicate up-front, allowing the community opportunities to respond. I'm hoping 'facts promptly available + more brains = better decisions if not better solutions'.

2) I agree with you that frustration overcame my better judgment in stating my (sample size of one person) decision some years back. What you didn't (and couldn't have known) was the emails inquiries I sent (written sans emotions) that were never responded to…but I digress and it's ancient history anyways. Still no excuse for voicing a past choice which has no relevance whatsoever to the issue at hand. 'Shooting from the hip', guilty as charged. 8)

For the record, I never wrote nor infer to hang the project management in effigy. If I don't believe in SETI, I wouldn't have returned given the opportunity and time.

My poorly-articulated email was written with the hope of gaining more clarity on the issue. To everyone offended by my post, my sincerest apology.

What I'm trying to point out:

First, you're assuming that this was something that the project did intentionally. If you read Eric's post, he clearly says it was unintentional.

If you have a big software project, and a tiny staff, there are going to be surprises.

That's why I suggest (strongly) that we cut them some slack. That we ask if they're aware of the issue before we start talking about "policy changes."

"The project is trying to make us angry" is an all too common theme in the forums -- and it never turns out to be correct.

From your later post, you're assuming that the official project has time to answer individual E-Mail messages from the active participants, and the truth is, they don't. They don't claim they can, or will.

It's pretty clear that at least two people read the forums, and while they don't always answer, we do see problems get fixed -- we see serious problems fixed quickly.

... and we get news from Matt most days (but not every day).

---