34 channels left on the three remaining tapes. Could be getting dried up ...

---

34 channels left on the three remaining tapes. Could be getting dried up ...

That'll take a load off of the servers.

Edit- now down to 24 on 1 file.
Edit- make that 16.
Edit- make that 0.
Last 6 are in progress.

No more till they load up some new files, hopefully tomorrow some time.

---

Grant
Darwin NT

No more till they load up some new files, hopefully tomorrow some time.

Soon, I hope. Already below freezing and snow and colder temps are in the forecast. May have to add some Einstein when I awake ...

---

No more till they load up some new files, hopefully tomorrow some time.

Soon, I hope. Already below freezing and snow and colder temps are in the forecast. May have to add some Einstein when I awake ...

Nothing coming down the pipe for hours now, "no tasks available".
Doesn't bode well for tomorrow's outrage.

---

Humans may rule the world...but bacteria run it...

No more till they load up some new files, hopefully tomorrow some time.

Soon, I hope. Already below freezing and snow and colder temps are in the forecast. May have to add some Einstein when I awake ...

Nothing coming down the pipe for hours now, "no tasks available".
Doesn't bode well for tomorrow's outrage.

Yeah, no tapes in queue to get split, so no work until some get loaded, apparently manually.
I might have to borrow a cat to stay warm :)

---

Eric tried to get things going last night by remote, but could not.
He said he will go at it again this morning after he confers with Jeff.

Meow.

---

"Time is simply the mechanism that keeps everything from happening all at once."

If I/O contention is the issue, I suppose it would depend on what I/O is causing the bottleneck. The GBT splitters are all on Centurion, and I don't see any other processes that would contend with them there. However, they must be hitting the BOINC DB, probably on Oscar, and feeding the split files to the scheduler over on Synergy. The file deleters are over on Georgem and Bruno, so it wouldn't seem as if they would contend with the splitters anywhere but at the DB.

Keep in mind they are all dealing with the same data files on the one sever, and the one database on the one server.
Also the rate work is being returned is also having an impact on things; when the received-last-hour falls back the splitters & deleters are able to both do a bit more work. There's a lot of disk activity when just a single WU is sent out, and then when it's result is returned. With 145k WUs per hour being returned & sent out- that's one hell of a file server load, not to mention the database keeping track of everything.

These comments have lead me to a possibly naive, but very basic question. Is BOINC truly scalable? My gut feeling, having never done a single credit on any other projects and thus don't know their volumes, is that it must be, but if so then is it a problem with how our work is configured and distributed, or how SETI was originally designed to do work, the hardware just isn't up to the task, or something else?

I believe (but don't quote me) that SETI was the original distributed computing project. Which is cool and all that, but that might carry some drawbacks as well. Being the originator or something (oh, I don't know, cell phones, "high speed" internet) has sometimes locks you into a certain, usually quite expensive set of circumstances, and when the 2nd gen of whatever comes along from competitors who take your thing and improve on it, you're often stuck with what you have, and it's very expensive to upgrade, especially if there has been a paradigm shift.

I am wondering if we are sort of in that situation right now? We were the first, blazed the trail and lead the way, and then those that followed us, saw it was great, but saw the shortcomings on how we initially did it as well, and then made adjustments and improvements to theirs that we couldn't easily make, due to the investment in time and treasure already invested, as well possibly in trying to keep with the stated goal that we are trying to support almost device, old to new (not really, but you know what I mean), and that inability to optimize due to this might be helping cause these headaches?

I honestly have no idea if what I proposed has any basis in reality or not, as I haven't been on the other side of things from the day I processed my first WU. I am just tossing out an idea as to what might be part of the reason we're dealing with DB issues and such. Is it hardware limitations? Software limitations? Inherent design limitations? I guess that in the scheme of all things computing, we really are pretty small fry. I mean, think of all the data that the NSA is processing every day. Yes, I know, look at their budget, all the hardware and personnel they can toss at any problem, I guess I'm just babbling about proof of concept, or maybe nothing at all, and just wanted to get some thoughts from others who know all of this stuff _Much_ more deeply than I will ever know.

---

I wonder if they could sort the database and move most of it into an archive database. All the work that is done and has nothing left in the field, thus leaving a much more manageable database active and online. Then the weekly outage would just sort the active database and move whatever has been completed during the week to the archive.

I know this sounds too simple to be possible, but might that be possible? Some database inquiries would have to be rewritten to access the archived information.

I dunno, just spitballing.

Meow?

---

"Time is simply the mechanism that keeps everything from happening all at once."

Tapes are beginning to appear, slowly. IIRC, there's quite a long pre-processing phase, which we don't see: as they emerge from that, they pop up automatically in the splitter queue.

Tapes are beginning to appear, slowly. IIRC, there's quite a long pre-processing phase, which we don't see: as they emerge from that, they pop up automatically in the splitter queue.

Well done, Eric and Jeff!

---

"Time is simply the mechanism that keeps everything from happening all at once."

Looks like break time is over. Work is starting to slowly build up again.

---

~Chris

I wonder if they could sort the database and move most of it into an archive database. All the work that is done and has nothing left in the field, thus leaving a much more manageable database active and online. Then the weekly outage would just sort the active database and move whatever has been completed during the week to the archive.

I know this sounds too simple to be possible, but might that be possible? Some database inquiries would have to be rewritten to access the archived information.

I dunno, just spitballing.

Meow?

+1

---

Hello,
Everytime then the WU are withdrown, my crunchers encounts the same behavior: the slower & less core one, which has few WU's left to crunch, receives new WUs , before the second cruncher (faster & more cores) which is totally withdrown of CPU WUs , receive it's new batch. Also when it receivs it got first GPUs (which some are already from the previous batch) and no CPU WUs. How schould I configure it for letting more CPU WUs be downloaded in advance instead of GPUs? Every outrage I would need some 100 CPU WUs more to have the work sustained on the faster machine.

Results ready to send : one ????
EDIT: Just changed to zero.

---

To overcome Heisenbergs:
"You can't always get what you want / but if you try sometimes you just might find / you get what you need." -- Rolling Stones

Hello,
Everytime then the WU are withdrown, my crunchers encounts the same behavior: the slower & less core one, which has few WU's left to crunch, receives new WUs , before the second cruncher (faster & more cores) which is totally withdrown of CPU WUs , receive it's new batch. Also when it receivs it got first GPUs (which some are already from the previous batch) and no CPU WUs. How schould I configure it for letting more CPU WUs be downloaded in advance instead of GPUs? Every outrage I would need some 100 CPU WUs more to have the work sustained on the faster machine.

Generally, if you allow both CPU and GPU work, the servers determine which to send you. You can temporarily turn off fetching of GPU WUs in BOINC (in Advanced mode) under the Activity tab. Until you turn GPU fetch back on, you will get only CPU WUs.

---

So would now be a good time to panic?? ;)

Just kidding....why I have back up projects. Giving beta a test, thought I'm not sure what we are looking at there...(only 1 machine and only 1 work unit per card)...Einstein is getting a boost from this.

---

My backup project is to improve the code and run local tests.

---

To overcome Heisenbergs:
"You can't always get what you want / but if you try sometimes you just might find / you get what you need." -- Rolling Stones

My backup project is to improve the code and run local tests.

Recovering some of those 5,300+ ghosts you've created wouldn't be a bad use of your time, either. Having those locked away when other people are starving for work is not particularly helpful.

How does one have so many errors and invalids?

He is testing a cuda alpha application, so there is bound to be some teething issues.

---