The four disks from AO have arrived - about 5TB of data. I have queued them up for pre-processing (radar blanking) so new SETI@Home workunits should be going out soon.

---

That´s great news, looking forward for some more SETI work!

---

Nice... finally dry spell coming to an end (it will be difficult leaving E@H home though with the higher RAC!)

Two queries:

1) Is there enough storage (ie drive units) with this sudden amount of work? (Money burning hole in my pocket... heh.)

2) Is there going to be any Green Bank work mixed in, now or in the near future?

---

The Cricket graph is showing a big spike. That might be the new data, I hope. A question I have is how long will 5 TB of data last?

---

5TB of data would theoretically be:

5 x 1024 x 1024 x 1024 x 1024 = 5,497,558,138,880 kilobytes
5497558138880 KB / 365 KB = 1,5061,803,120 Multibeam tasks (average 365 KB task size).

And if there were APs to split (which I doubt):
5497558138880 KB / (8 x 1024 x 1024) = 655,360 AP tasks (8 MB task size).

But there's probably some loss there. And perhaps some parts unusable.

---

5TB of data would theoretically be:

5 x 1024 x 1024 x 1024 x 1024 = 5,497,558,138,880 kilobytes
5497558138880 KB / 365 KB = 1,5061,803,120 Multibeam tasks (average 365 KB task size).
...

5 x 1024 x 1024 x 1024 x 1024 = 5,497,558,138,880 BYTES

Multibeam tasks actually only have 256K (262144 Bytes) data, but it's encoded in a fashion similar to uue which makes it larger. Also, splitting uses about a 20% overlap between WU groups so a better estimate would be

(5497558138880 / 262144) * 1.2 = 25,165,824 Multibeam workunits.

It usually takes about 2.1 tasks on average per Multibeam workunit, so 52,848,230 tasks or so is my estimate.

                                                                  Joe

Nice... finally dry spell coming to an end (it will be difficult leaving E@H home though with the higher RAC!)

A very pleasant surprise which I noticed as well. Is there some online link which provides the RAC on a per project basis for comparison purposes?

---

Joy !

---

mambo

5TB of data would theoretically be:

5 x 1024 x 1024 x 1024 x 1024 = 5,497,558,138,880 kilobytes
5497558138880 KB / 365 KB = 1,5061,803,120 Multibeam tasks (average 365 KB task size).
...

5 x 1024 x 1024 x 1024 x 1024 = 5,497,558,138,880 BYTES

Multibeam tasks actually only have 256K (262144 Bytes) data, but it's encoded in a fashion similar to uue which makes it larger. Also, splitting uses about a 20% overlap between WU groups so a better estimate would be

(5497558138880 / 262144) * 1.2 = 25,165,824 Multibeam workunits.

It usually takes about 2.1 tasks on average per Multibeam workunit, so 52,848,230 tasks or so is my estimate.

                                                                  Joe

Let's say that the loose change (2.8 million MB tasks) vanishes into the 'out in the field' caches - so to an order of magnitude, 50 million tasks and we process 50 thousand an hour.

So, around a thousand hours of work - can't estimate closer than that without any knowledge of the ARs of the recordings. 6 weeks of work should keep us warm through the holidays.

6 weeks of work should keep us warm through the holidays

Ah, an answer I can understand. Thanx

---

That's all good and well Jeff, but how about the rebuilding of the AP database? We haven't heard a word about that since Dec 2, when Eric predicted that it could be finished on Saturday, and that he should post updates during the week (which didn't happen).

Saturday is tomorrow.........I'm not going to look gift horses or WU's in the mouth. Anything to crunch is a plus.

---

"Sour Grapes make a bitter Whine." <(0)>

6 weeks of work

It looks like it is already finished.
No more are available.

6 weeks of work

It looks like it is already finished.
No more are available.

Now how do you work that out when there are 3 files currently being split as we speak? :-O

Cheers.

Yay! At last the wheels are moving again!
http://setistats.haveland.com/

5 x 1024 x 1024 x 1024 x 1024 = 5,497,558,138,880 BYTES

lol, did I go one too many? Ah yes. ;-)
So divide by 1024...

---

Wow, great news !
Even though I run another project, my preference and loyalty has always been for Seti.
Thank you for the team of Seti for their efforts.

---

On ne peut voir au-delà des choix qu'on ne comprend pas.

Thanks, 200 MB tasks in progress as we speak here :D

that's a great Sinterklaas(Dutch traditional holiday where gifts are given to children by a Santa Claus kind of folk hero) present !

---

Woohoo, more work to process!

---

Well, I see on the server status page there's no backlog of WU's to send, no matter how often I update the page. All of my computers except one have SETI WUs now. Of course, the one that doesn't is my best one with 2 6-core NUMA processors. So I've got 24 virtual processors sitting idle if it wasn't for the Bitcoin fundraiser. I just manually grab a load of bitcoin, process it, check SETI and if no tasks there, grab another load of BTC WUs. Hopefully, I'll get lucky before bedtime and grab enough SETI WUs to work through the night.
My goal for the year is 20M credits, and I'm soooooooooo close. So I want this particular machine working SETI. I figure once I reach that 20M goal, then I'll let all of my computer work the BTC WUs until the end of the campaign.

Well, I see on the server status page there's no backlog of WU's to send, no matter how often I update the page. All of my computers except one have SETI WUs now. Of course, the one that doesn't is my best one with 2 6-core NUMA processors. So I've got 24 virtual processors sitting idle if it wasn't for the Bitcoin fundraiser. I just manually grab a load of bitcoin, process it, check SETI and if no tasks there, grab another load of BTC WUs. Hopefully, I'll get lucky before bedtime and grab enough SETI WUs to work through the night.
My goal for the year is 20M credits, and I'm soooooooooo close. So I want this particular machine working SETI. I figure once I reach that 20M goal, then I'll let all of my computer work the BTC WUs until the end of the campaign.

The server status page only gets generated once every 10 or 20 minutes. No matter how many times you refresh it, take note of the important bit at the top: "[As of 6 Dec 2014, 1:00:10 UTC]." The next refresh will either be 1:10, or 1:20. It is supposed to be a 10-minute interval, but sometimes it takes more than 10 minutes for the script to run all the way through generating all the values, so it just waits until the next 10 interval.

Regarding having trouble getting work.. Some people have found that having a huge cache setting, or requesting a very large number of seconds of work, the scheduler tends to not want to give you WUs. Change your cache settings down to something small, like 0.1 days. Once you get a few WUs, then you can go back to large settings and it seems to be a little more cooperative.

That aside.. you also have to remember there are 100,000+ hungry machines DDoSing the server asking for work. The feeder queue (what's available when the scheduler assigns work to somebody) can only hold 200 tasks at a time, and only refills every 2-5 seconds, so it is very much luck of the draw as to when your request gets processed versus what's available in the feeder at that same moment.

Just be patient.. it'll be a few hours before things start to settle down.

---

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