Increasing Numbers (Jul 01 2009)

Ahh.. O.K., the opt. crew is very quick! ;-)

I don't crunch AP.. because current I have only a GPU cruncher for SETI@home Enhanced (MB). :-)

____________


>Das Deutsche Cafe. The German Cafe.<

Thanks Sutaru, the link definitely answers my initial question.

I understand this http://lunatics.kwsn.net/index.php?module=Downloads;sa=dlview;id=198 as if there already is an opt app for astropulse 505 :-)

Andreas

thanks for the anology - since the guy is too busy I guess I just shut down!

That's not the answer. Another request just 30 milliseconds later could be granted some work. You just need to keep asking and hit it right.

Not true for last night: (July 1) I left WU request on ALL night and didn't get one work unit! I think the splitters are (currently, at least...) making too many CUDA WU's and not enuf CPU WU's.

So, of that "1.5 million WU's", how many are already designated as CUDA??? Is there some way to tell in Berkeley? It doesn't (necessarily...) have to be visible to the crunching public..

Now we're getting connect() failures on upload
____________

Not true for last night: (July 1) I left WU request on ALL night and didn't get one work unit! I think the splitters are (currently, at least...) making too many CUDA WU's and not enuf CPU WU's.

So, of that "1.5 million WU's", how many are already designated as CUDA??? Is there some way to tell in Berkeley? It doesn't (necessarily...) have to be visible to the crunching public..

Not true. CUDA work and CPU work are both the same and are both MultiBeam work units. It is your host computer that makes the assignment to use the CPU's or CUDA when the work unit is received. Berkeley servers don't care which app (603 or 608) crunches the MultiBeam work units.

hi ! seti@home 10 year video :)

fichier.ppt & fichier.pdf -_-

@+
____________
SETI@Home Informational message -9 result_overflow
with a general handicap of 80% and it makes much d' efforts for the community and s' expimer, thank you d' to be understanding.

What? This is unacceptable! Oh look, "videos from the SETI@home 10 year anniversary!" (Easily distracted) Oh, I’m going there, What was I talking about?


Dave

A guy behind a window (the job) gets a request for a work unit and he grabs one off the queue and hands it to you. He keep doing this until the queue is empty. When it is empty he hangs up a sign No Jobs Available and swivels his chair around to the database and grabs 100 work units to fill his queue up. When he is done and his queue full again he turns back around and takes the sign down.

When the load is light, the man is facing you most of the time and you get work most of the time. When the load gets very heavy the man spends most of his time filling the queue from the database and you see the no work sign. It doesn't matter how much work is available to fill his queue.

That's not correct. It doesn't wait for the queue to be empty before fetching more.

Every five seconds (by default; SETI may be changing that delay), the feeder checks if there is any free space in the queue and fills it with data from the database. And while the feeder is busy doing that, querying the database, the schedulers can still get items from the queue.