The replica mysql database on sidious recovered more or less just fine. It may be ever so slightly out of sync with the master database. This means we'll probably rebuild it during the next weekly outage just to be sure.

The scheduling server was up and down yesterday afternoon and this morning. The scheduler CGIs have been segfaulting and adding core dumps caused the system to grind to a halt, needing a reboot. Turns out the problem wasn't in the CGI, but in apache itself (or the fastcgi module). This has been a problem in the past. We seem to have to tweak various apache parameters at random times, based on a chaotic, unpredictable equation involving current resources/demands, mysql health, network health, system health, various queue sizes, etc. Simply reducing the MaxClients to a much lower number caused the segfaults to disappear while still servicing all incoming requests.

We're running low on data to send out, and we're in a murky period where the weekend is rapidly approaching and we are still awaiting the latest shipment of raw data drives from Arecibo. We could pull up as-yet-unanalysed data from our archives, but the offsite storage archive (HPSS) is undergoing several upgrades and have been offline for days. We'll see how this all pans out...

- 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 Matt as always for the update.

Seems a little quiet round here these days. Only 1 post yesterday!

I hope work doesn't run out. Still that will give em something to moan about over in NC :-)

---

Thanks for the info Matt.

Any part of Southern Utah you have not been to???

And one more question..........is AstroPulse a dead project now???

---

Boinc....Boinc....Boinc....Boinc....

No, I am sure that AstroPulse is not dead. As Matt explained below, ALL the data for AP has been split and sent out. New data from Arecibo is expected soon.

If the hard drives with new data doesn't arrive on Friday, there is a good possibility that MultiBeam WUs will also be exhausted over the weekend, as well as AstroPulse.

In other words, SETI may have absolutely no work to send out over part of the weekend and possibly even into next week.

Whit

In other words, SETI may have absolutely no work to send out over part of the weekend and possibly even into next week.

I hope new work arrives tomorrow, if not I think this will be the first time I have ever seen Seti run out of work. I will not be one to moan because I think the whole crew does a great job at the lab. Sometimes you can't help delays with the mail and courier services as annoying as it is.

---

In other words, SETI may have absolutely no work to send out over part of the weekend and possibly even into next week.

I hope new work arrives tomorrow, if not I think this will be the first time I have ever seen Seti run out of work. I will not be one to moan because I think the whole crew does a great job at the lab. Sometimes you can't help delays with the mail and courier services as annoying as it is.

This is when a 4+ day cache comes in handy. I should be fine until about Wednesday, even though it's only a 4-day cache.

---

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

Thanks for the info Matt.

Any part of Southern Utah you have not been to???

And one more question..........is AstroPulse a dead project now???

AP is not dead, on Beta V5.01 has just started testing.

In other words, SETI may have absolutely no work to send out over part of the weekend and possibly even into next week.

I hope new work arrives tomorrow, if not I think this will be the first time I have ever seen Seti run out of work. I will not be one to moan because I think the whole crew does a great job at the lab. Sometimes you can't help delays with the mail and courier services as annoying as it is.

This is when a 4+ day cache comes in handy. I should be fine until about Wednesday, even though it's only a 4-day cache.

I run multiple projects on each computer, and it would take about 15 specific projects down at the same time to turn off work to the least capable of my computers.

---

BOINC WIKI

We could pull up as-yet-unanalysed data from our archives,

Wouldn't that be everything from day 1 to now?

---

me@rescam.org

Wouldn't that be everything from day 1 to now?

It could be but I would think it will just be the data that hasn't been analyzed that is in the archives. I have raised the question before. Why don't we process all the old data first? I think the main reason is because to date we simply don't have enough computing power to keep up with the data volume. If there is another reason please correct me.

---

Thanks so much for the update, thus i could understand what happened here with my Computer, with downloaded none during yesterday... I was thinking something was wrong here!

---

Welcome to the message boards michael.

And yes it can be confusing trying to work out where the problem is sometimes, but there usually will be posts in the number crunching forum when there is problems with the Seti servers.

Also most of us have bookmarked the Server Status page, and have a look at it whenever problems arise.

Seems like for the first time in a very long time, I am going to run out of work, should be in about 5 hours time.

Ah well, will give the computer a nice rest as it has been crunching 24/7 for the last 2 years solid! Give or take the inevitable occasional windows reboot required.

Will be patient until it can send some work, seems to have gone through the 4 day cache fast though.

Happy SuperBowl day :-)

---

Seems like there is a small amount of work filtering through, since my last post I have got a few tasks come in.

---

Seems like there is a small amount of work filtering through, since my last post I have got a few tasks come in.

If work expires, it will be resent. So there will be small amounts.

---

Server Status as of 1 Feb 20:00:10 as of * 47 minutes says there are 33,474 Results ready to send. Spliters are spliting the last 5 channels at present, tape 18dc08aa is upto chanel 13. Cricket Graph says as of Feb 1 11:52:22

Average bits in Cur: 28.43 Mbits/sec
Average bits out Curr: 14.45 Mbits/sec

This is my 2 cents worth for the crunchers that like technical information
7 new data tapes have been added while I've been typing this post. A big thank you to the person who has come to the lab to add the work to queue on a Sunday morning. I didn't think we will run out of work now. Thank you again to the staff member that came into the lab

---

I think the main reason is because to date we simply don't have enough computing power to keep up with the data volume. If there is another reason please correct me.

I'd have to disagree with that. I remember a post by Matt a long time ago asking for assistance at Beta when developing the enhanced workunits or SETI would run out of work. That's why I asked NEZ to attach to Beta and he graciously complied.

---

me@rescam.org

I'd have to disagree with that. I remember a post by Matt a long time ago asking for assistance at Beta when developing the enhanced workunits or SETI would run out of work. That's why I asked NEZ to attach to Beta and he graciously complied.

I think the main reason is because to date we simply don't have enough computing power to keep up with the data volume.

ok heres the thread i based the information on that i gave you.

---

7 new data tapes have been added while I've been typing this post. A big thank you to the person who has come to the lab to add the work to queue on a Sunday morning. I didn't think we will run out of work now. Thank you again to the staff member that came into the lab

Adding my thanks for the extra work added to the queue on a Sunday.

We're almost at the end of the 18dec 'shorty' (G-ALFA Continuum Transit Survey) recordings. Let's hope the 'tapes' brought back out of storage contain meatier fare, to damp down the bandwidth demand a bit. Maybe even some VLARs, to really damp down the CUDA demand ;-) ?

Do the staff have access to an internal graph like Scarecrow's?



See how the clear trendline jumps on 17 December (CUDA v6.05 day), declines again as the bugs come to light, then starts to climb strongly on 21 January (CUDA v6.08 day).

We're now returning consistently double the number of results we were before CUDA.

Matt, soon after the first CUDA launch, you did a quick snapshot and came up with a figure of 3% of results returned having been processed by a CUDA application. Would you have a moment to re-run that query now we seem to be in full production?