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.

BINGO!
That is why there is an automatic random back off built into BOINC.

Took y'all advise- out of a 3 day cache the guy got unbusy enough to give me 10 hours. Back to my solution Take the rig off and not waste cycles asking for work. Gives the super cruchers more to work with and saves bandwith applying for a job.
Classic WU= 7,237 Classic Hours= 42,079

To make up for that, how about some videos from the SETI@home 10 year anniversary? I'll link these to the home page soon enough. Consider this a sneak preview for those who read these threads. Let me know if there are problems downloading/viewing these mpegs.

HOOORAYYYYYY!!!!!!!!!!

I've been chomping at the bit for these since May 21st. When it's too hot to go outside this weekend, I'll be inside watching these. Thanks for getting them done before the holiday!Running S@H since Day 1 -- May 14th, 1999!

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.. Hello, from Albany, CA!...

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.Boinc....Boinc....Boinc....Boinc....

To make up for that, how about some videos from the SETI@home 10 year anniversary? I'll link these to the home page soon enough. Consider this a sneak preview for those who read these threads. Let me know if there are problems downloading/viewing these mpegs.

That's awesome, Matt. But why on EARTH are you hosting them on SETI's servers? Those could be eating a lot of bandwidth for SETI. Can you post them on YouTube instead?

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.

But, if they're both the same in Berkeley's WU queue, why do people get the "No WU's available for your CPU, GPU units available" line? (in red yet!) (or words to that effect...)

I've gotten that line many times when I' have had CUDA units up the ying-yang, but wanted CPU units (because I had cold cores...) on my CUDA capable Quad core computer! (like last night!, although I didn't get the line last night...) (of my 5 computers, only one is CUDA capable...). Hello, from Albany, CA!...

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.Contribute to the Wiki!

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.

But when things are really busy, the 100 tasks can disappear in a fraction of a second.BOINC WIKI

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.

But when things are really busy, the 100 tasks can disappear in a fraction of a second.