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

Yes, that's one of them, but better to follow this link

http://lunatics.kwsn.net/index.php?module=Downloads;catd=31

which shows the proper choice of SSE or SSE3.

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!

Any chance of a link to the Powerpoints shown at the Anniversary?

---

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

Now we're getting connect() failures on upload

---

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

it's the opposite for me. not ENOUGH cuda, and way too much cpu work units.
my cuda card is now sitting there doing nothing. i have a few days left of mb for the cpu.

it's the opposite for me. not ENOUGH cuda, and way too much cpu work units.
my cuda card is now sitting there doing nothing. i have a few days left of mb for the cpu.

Follow Message 913171 in order to heat up Cuda
by converting some of 603 into 608 WUs.

---

Who the hell is General Failure and why is he reading my harddisk?¿

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

---

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

LOL

---

I've got 1 for ya. I've been sittin' here for 3 days w/no WU's period. Don't quiet know what the issue is around CUDA tho'. However I digress. I've got 35+ gig assigned in pref's, but the sys is tellin' me I another 32 meg...what gives. Appreciate your input. stevehusker

You should post about problems at Questions and answers.

The message is probably about memory space, not disk space.

Gruß,
Gundolf

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.

That's definitely true. But the original analogy is inaccurate either way :)

---

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

That's definitely true. But the original analogy is inaccurate either way :)

Seems to me, from a computer scientist's point of view, that this system does not scale up well. It would make more sense to have two buffers (queues) in the feeder. One thread reads from buffer #1 and gives tasks to clients requesting work. The other thread is busy filling buffer #2. When buffer #1 is empty, both threads swap buffers. Hopefully, someone smarter than me knows how to program this most efficiently, but this approach would avoid the "fill the queue" delay that the feeder currently has. Recall that Matt mentioned that the "fill the queue" delay is quite significant, given that the database is always hammered.

Perhaps I should bring this up with the BOINC development team, if there is an agreement from someone on the SETI staff that things this idea is worth pursuing.