. . . just came back up 'blazingly fast' - must be the Triple Shot Cappuccino's ;)

---

BOINC Wiki . . .

Science Status Page . . .

Ok, now that the web page is fixed, so why aren't the assimulators driving their queue to zero faster?

Speaking of reassigning tasks:

Matt, could you be so kind and trash this wu? It's been causing trouble for me and all others who have been crunching it...

TIA

It's already reached "Too many errors" status so won't be sent out again. The only host still working on it is running BOINC 5.2.13, which doesn't support server aborts, so there's nothing for Matt to do.

                                                                Joe

It's already reached "Too many errors" status so won't be sent out again. The only host still working on it is running BOINC 5.2.13, which doesn't support server aborts, so there's nothing for Matt to do.

                                                                Joe

Thanks, Joe, for pointing this out. I was actually thinking that boinc should take care of such situations by itself. Relieving.

Since disk space and db performance is a hot issue on this thread and the right people are here, would someone review for me why I have so many validated wu's remaining when I review my computers each morning?

That would be the assimilation process getting behind... That was the discussion about the optimized application which turned into possibly a bad host... The WUs have to be assimilated before they can be deleted/purged, and so if they're not assimilated, they can't be deleted/purged... ;-)

Thanks. Is there a target value for the number waiting to be assimulated, or is it that they don't have enough assimulator processes launched to catch up and force the average number toward zero.

According to the good old Scarecrow graphs, the assimilator queue has been steadily reducing since about 06:00 UTC today. It should carry on down to an effective zero (no lower bound), but clearly not very quickly. Maybe Matt will have to build some more copies, and find a server to run them on, if/when he gets the Cisco bottleneck sorted out and they recruit all the extra volunteers they're looking for.

Thanks. I guess that it comes down to have enough assimulators running and there is no desire to keep validated results hanging around.

Is there a succinct description of what causes the purge queues to be so large? Purge means to me that the buggers are waiting to be deleted, and so I get that confused with the assimulators, I guess.

Thanks. I guess that it comes down to have enough assimulators running and there is no desire to keep validated results hanging around.

Is there a succinct description of what causes the purge queues to be so large? Purge means to me that the buggers are waiting to be deleted, and so I get that confused with the assimulators, I guess.

The purge queues are deliberately set at 1 day elapsed time, so that people like you and me get a chance to look at our results before they disappear for good. If the assimilation delay is zero (as it normally is), then the purge queue gives an idea of the 24-hour turnover - 900,000 results, or 450,000 WUs, on average: more during a shorty storm.

Oh it looks like I had two work units but kicked out do to this
NOTE: The number of results detected exceeds the storage space allocated.

so I update my client drive space to 75gig's

Oh it looks like I had two work units but kicked out do to this
NOTE: The number of results detected exceeds the storage space allocated.

so I update my client drive space to 75gig's

NO, the "storage space" referred to in that message is not disk space.

You probably also saw the line

SETI@Home Informational message -9 result_overflow

on the line above.

The programmers allowed for a maximum of 30 data points (Spike, Pulse, Triplet, Gaussian) in any one result - any more than that, and the program doesn't bother to waste any more time on it: it ends early, and moves on to the next one.

You'll probably see that your 'wingman' also finished early, with the same message. Occasionally, however, one host finds 31 pulses - it's only ever pulses - and finishes early, while a different host runs the normal time and finds far fewer. That's a known (but rare and unusual) bug that the programmers are trying to track down - don't worry about it, it's not your fault.

Just between you and me... In addition to the outbound traffic squeezing through our maxed-out router, I am now sneaking our an additional 5-10% over the campus net. This is thanks to the simple/useful "pound" load balancing utility. The campus net can definitely handle this tiny increase. In fact I might bump up the percentage. But don't tell anybody. Mwha ha ha. [edit: I brought that percentage back down to 0% an hour later - we'll keep this extra power in our back pocket for now.]

And who do you think is reading these forums?

Just between you and me... In addition to the outbound traffic squeezing through our maxed-out router, I am now sneaking our an additional 5-10% over the campus net. This is thanks to the simple/useful "pound" load balancing utility. The campus net can definitely handle this tiny increase. In fact I might bump up the percentage. But don't tell anybody. Mwha ha ha. [edit: I brought that percentage back down to 0% an hour later - we'll keep this extra power in our back pocket for now.]

And who do you think is reading these forums?

Well... you and me. ;-)

---

Just between you and me... In addition to the outbound traffic squeezing through our maxed-out router, I am now sneaking our an additional 5-10% over the campus net. This is thanks to the simple/useful "pound" load balancing utility. The campus net can definitely handle this tiny increase. In fact I might bump up the percentage. But don't tell anybody. Mwha ha ha. [edit: I brought that percentage back down to 0% an hour later - we'll keep this extra power in our back pocket for now.]

And who do you think is reading these forums?

Well... you and me. ;-)

Me too...

:gets out old AOL 3.5" floppy disk:

Thanks. I guess that it comes down to have enough assimulators running and there is no desire to keep validated results hanging around.

Is there a succinct description of what causes the purge queues to be so large? Purge means to me that the buggers are waiting to be deleted, and so I get that confused with the assimulators, I guess.

Remember that some of this is a balancing act: when you "speed up" the assimilators, that means less resources for splitters, schedulers, validators, etc.

One might decide to let the validator queue grow in order to split more work and keep feeding the hungry crunchers.

---

Oh, come on now.......
I have read the forums, and everybody knows that Seti has unlimited server and bandwidth resources available....they are just taunting us....LOL...LOL...LOL...

---

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

Darn you mean that all misunderstaning of this that and the other thing, was all because someone didn't prof read the code program? oh well just onther excuse to build and expand the gamer computer, I do see when my chip gets a little on the hot side, is when those little nice fine pen like frequency levels in the lower levels graphics get to be wider and over bound. right or is that part of the program too?

Wow. Busy thread. Some responses.

The assimilator queues are lagging due to simultaneous index builds on the science database - so some I/O contention. No problems. They'll push through eventually.

I'm surprised you answered at midnight your time...

Well, computer geek by day, musician by night. My schedule is quite erratic and I check in whenever I can but make no 24/7 guarantees.

And who do you think is reading these forums?

The cheekiness was for entertainment - I know we're being watched. Anyway my "fix" was really to see how much we needed to push beyond our current cap (or if we even could). I thought it was going to be like 1-2 Mbits that would get lost in the noise. Nope - more like 6-10. That's why I shut it off.

- Matt

---

-- BOINC/SETI@home network/web/science/development person
-- "Any idiot can have a good idea. What is hard is to do it." - Jeanne-Claude

I don't waste money on cappuccinos. Caffeine tablets do the job and cost only about 1/50 as much.

---

Darn you mean that all misunderstaning of this that and the other thing, was all because someone didn't prof read the code program? oh well just onther excuse to build and expand the gamer computer, I do see when my chip gets a little on the hot side, is when those little nice fine pen like frequency levels in the lower levels graphics get to be wider and over bound. right or is that part of the program too?

No, this is a design decision.

It was decided that any result with more than 30 Spikes, Pulses, Triplets, and/or Gaussians was probably hearing a terrestrial signal source, and as such would show an unusually high number of signs of intelligence -- that we already know about.

... assuming of course that mankind is intelligent, which is another debate.

---

Are the SQL queries that Mat referenced in the source tree? If they are, can someone point them out to me? (maybe I missed them because they're embedded in code...) A quick scan of the svn web interface didn't turn up anything obvious.

Thanks!

Occasionally, however, one host finds 31 pulses - it's only ever pulses - and finishes early, while a different host runs the normal time and finds far fewer. That's a known (but rare and unusual) bug that the programmers are trying to track down - don't worry about it, it's not your fault.

Here's an example of one of the "rare and unusual" workunits.

Thus far, my rig has returned no pulses, but two others (here and here) have each returned 31 pulses.

I post this in the hope that it might assist the programmers in tracking down the bug.

---