The nightmare that was my 2013 schedule is behind us. Actually 2014 may be better, or may be worse. Time will tell.

Ugh, it's been a while. Once again I'm finding myself in major-catchup-mode when trying to figure out what to mention. On the surface, it doesn't seem that much has been happening (maybe), but we've been quite busy on various projects. Here's some of them off the top of my head.

First, neither the perfect solution nor the money ever appeared to magically speed up our science databases, so were are working on plan B: vastly reduce the size of these databases so we can actually work with them! We've been coming up with clever ways to quickly bring our final science results down to less than 10% its original size without a minimal, perhaps zero, compromise in sensitivity. That's one project. Maybe we'll create a new client which can do this reduction for us (which will require much larger workunits).

Second, we recently obtained a generous donation of a lustre file server from Xyratex. There was some effort to install this system and ramp up on managing lustre, but now we have a 120TB sandbox to play with. Currently we're using it to house all kinds of data from various other SETI projects, or as a backup/SETI@home data buffer. As we get more comfortable with the system we'll push on it with more i/o intensive projects.

Third, as SETI@home chugs along we are also dividing our efforts working on various other SETI projects. This will all be clearer after we launch (no ETA as of yet) our new web site.

Meanwhile we had a few crashes recently. As we now have faster network inside the colocation facility and larger disk arrays, we are hitting some linux i/o limits causing CPUs to randomly lock up (requiring hard power cycles). Anybody have any tips on this front? I'm messing with /sys/block/device/queue/scheduler to see if that helps.

Also on of Eric's systems had a RAID6 on it which suffered 3 drive failures within a week over the holiday. Such cruel timing. We're recovering from that (it's backed up regularly) but until it's back on line other co-dependent systems are getting headaches.

Same old, same old. I'm looking forward to the newer web site, which will have more contributors and more information - one of our general problems over the years.

- 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

Thanks for the update Matt, welcome back.

Claggy

Thanks for the update Matt, welcome back.

Claggy

+1

Cheers.

Thanks for the update Matt, welcome back.

Claggy

+1 = >>>> 2

Thanks for the update Matt, welcome back.

Indeed!

---

Matt, thanks for the news!

I wish all a Happy New Year 2014!

* Best regards! :-) * Philip J. Fry, team seti.international founder. * Optimize your PC for higher RAC. * SETI@home needs your help. *

---

That's terrific news Matt. Thanks for keeping us up to date!

Thanks for the update Matt, welcome back.

Claggy

+1 = >>>> 2

+3 and HNY Matt ! :)

---

Good to hear from you, Matt.

---

David
Sitting on my butt while others boldly go,
Waiting for a message from a small furry creature from Alpha Centauri.

Thank you Matt for the update.

Maybe some of the chatter (not that has it been to loud lately) would die down, if you made your posts in the News Section.
Hearing from you is always good News to me, plus it would show on the front page.

Just a thought.

---

Pluto will always be a planet to me.

Seti Ambassador
Not to late to order an Anni Shirt

Glad to see you back in the lab, Matt. And thank you for the background info.
Upward and onward.

Do you have the drives you need to get Eric's RAID rig back in action?
Or do we need an emergency fundraiser to help get it back online quickly?

---

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

Thanks for the update, is wonderful to have some news and can't wait for the new developments! :)

Thanx for the update Matt:)

---

rOZZ
Music
Pictures

Thanks for the update Matt. You mention a server donation. When you've finally got that sorted, any chance of calling it: Curmudgeon

---

Regarding your Linux IO problems.

I wonder if you really are seeing lock ups or just non-responsive behaviour.

Not sure the specs on that machine. But I imagine it has quite a few GBs of RAM.
In which case I wonder if your hitting the VM writeback problem.

The kernel allows a certain amount of dirty data (data that needs to be written
out to backing store) to build up in memory. In current kernels, this can be as
much as 20% of your RAM that it will need to write out and can easily block
other IO causing long stall periods where it may seem that the machine has hung.

(These defaults where made in the heady days of having a machine with as much
as 64MB of RAM!).

It's also recognised that today even having a percentage at all isn't really
suitable and thus byte limits have also been introduced (but not used by
default).

So you may want to have a look at tuning

/proc/sys/vm/dirty_background_bytes and
/proc/sys/vm/dirty_bytes

Which ever of bytes or ratio is set last is what's used.

As to what to set them, that may take a bit of trial and error to see what works
best for you.

You could start out with say (8 & 24MB), you may well need to go quite a bit
higher, but you probably want to avoid having GBs of dirty data to be writing
out.

# echo 8388608 > /proc/sys/vm/dirty_background_bytes
# echo 25165824 > /proc/sys/vm/dirty_bytes

(Stick in /etc/sysctl.conf to make it permanent)

You can watch this in action with something like

$ watch -n 5 grep -e ^Dirty: -e ^Writeback: /proc/meminfo

You'll see the dirty value build then when it reaches the limit you'll see the
writeback value ramp up.

See https://www.kernel.org/doc/Documentation/sysctl/vm.txt

Cheers,
Andrew

We've been coming up with clever ways to quickly bring our final science results down to less than 10% its original size without a minimal, perhaps zero, compromise in sensitivity.

More news on that front?

A smaller science database will open the doors to a manageable Near time persistency checker?

---

Currently we're using it to house all kinds of data from various other SETI projects, or as a backup/SETI@home data buffer.

Why?

---

Never engage stupid people at their level, they then have the home court advantage.....

Currently we're using it to house all kinds of data from various other SETI projects, or as a backup/SETI@home data buffer.

Why?

Matt answered that question in the next sentence, ed:

As we get more comfortable with the system we'll push on it with more i/o intensive projects.

---

Donald
Infernal Optimist / Submariner, retired

Strange, very strange. I have downloaded the latest version and now all of my work downloads fail. What is happening?

---

It is best to ask for assistance with issues in the Questions and Answers forum or in Number Crunching. There's a lot of very knowledgeable people who can help you if you ask.