You know how every MB has spikes, triplets, pulses, gaussians, and auto-correlation counts? Every single one of those that gets found in every single WU.. becomes a new row in the respective tables. Based on what I'm seeing on my one cruncher, we've passed 4 billion tasks, and are nearing 1.75 billion WUs. Considering MB has five kinds of signals, and can have 30(?) of each, that adds up to a massive number of rows in the DB.

A technicality about this has bothered me. You remember that it has just been recently that Autocorrelation has been implemented as a parameter and added to the crunching regimen?

I was hoping Autocorr counts would show up in the Master Science Database table display on the Science Status Page. In that table you see the counts of Spikes, Gaussians, Pulses, Triplets. Each count, as noted, presumably a row in the table.

However, ever since the Autocorr parameter has been implemented, that count has never been added to the display.

I assume that the Autocorrelation counts are being added to the MSDb. And that no one on staff has had the time to program a change to add this count to the display. But I have no confirmation. Anyway, it would be nice to see the Autocorr counts compared to the other signal counts.

---

"It is often darkest just before it turns completely black."

You know how every MB has spikes, triplets, pulses, gaussians, and auto-correlation counts? Every single one of those that gets found in every single WU.. becomes a new row in the respective tables. Based on what I'm seeing on my one cruncher, we've passed 4 billion tasks, and are nearing 1.75 billion WUs. Considering MB has five kinds of signals, and can have 30(?) of each, that adds up to a massive number of rows in the DB.

A technicality about this has bothered me. You remember that it has just been recently that Autocorrelation has been implemented as a parameter and added to the crunching regimen?

I was hoping Autocorr counts would show up in the Master Science Database table display on the Science Status Page. In that table you see the counts of Spikes, Gaussians, Pulses, Triplets. Each count, as noted, presumably a row in the table.

However, ever since the Autocorr parameter has been implemented, that count has never been added to the display.

I assume that the Autocorrelation counts are being added to the MSDb. And that no one on staff has had the time to program a change to add this count to the display. But I have no confirmation. Anyway, it would be nice to see the Autocorr counts compared to the other signal counts.

The data on the Science Status Page, hasn't updated since: 4 Nov 2014, 23:30:05 UTC
As can be seen under the "Note: This page is still vastly under construction. More features are being developed. Read more about our future plans."

Patience is a virtue. Glad we have the updates, myself.

---

rOZZ
Music
Pictures

No, there can only be 30 signals total, in any combination of the 5 types. It can be 30 spikes, or 15 spikes and 15 pulses, or 22-2-2-2-2, but not 30-30-30-30-30.

Did not know that one. I always wondered what the actual signal count limit was for MB. Actually, I thought it had to do with the size of the result file (and I feel like I remember the limit being 30KB), not the number of signals found.

Interesting to know, then.

Which just means.. if we've had 1.75 billion WUs, and just for the sake of napkin-math we say that the average is 10 signals per WU, that makes 17.5 billion rows in total.

What I DO know about DBs is that you have to designate the size of each field, which means if it will hold text, then you would need to figure out what the absolute longest string of text will ever be for that field before you even start, or just let it go with the default, which is usually 256 or 512 characters, which also means bytes.

If we assume there are say..5 text fields and 10 numerical fields.. both being 32-bit values, whether float or integer (both are 4 bytes.. but I remember recently some integer values had to be upgraded to 64-bit, so we'll say they're all 8 bytes now), that makes 2640 bytes per row, no matter what data is actually in each field. 2640 bytes per row * 17.5 billion rows = 46.2 TB if it is not compressed.

I don't care what the DB engine is.. having to read through that many rows or bytes is an immense task.

---

Linux laptop:
record uptime: 1511d 20h 19m (ended due to the power brick giving-up)

Thanks Matt for the in depth news .Sounds like I've made the right desition . No seti and Just do Crypto on the GPU . 3 months wow should make a bit in that time so I can donate it to the course , which sounds like your going to need with the gremlins really having a right old feed on all the hardware

---

Thanks for the update Matt.

---

Pluto will always be a planet to me.

Seti Ambassador
Not to late to order an Anni Shirt

Regarding disc drives and drive life...

You might want to take a look at these:

https://www.backblaze.com/blog/how-long-do-disk-drives-last/
https://www.backblaze.com/blog/what-hard-drive-should-i-buy/

The second link should be accompanied by:

http://www.theregister.co.uk/2014/02/17/backblaze_how_not_to_evaluate_disk_reliability/

as a caution about doing good statistics.

--Jim

---