Is there a specific time for the crash, or is it just in the wee hours in a general sense??

As I remember it, it was a few minutes after midnight PDT, or after 07:00 UTC. I'll check a few logs.

The panic thread posts lead me to guess 10:30 UTC

Of course, if Synergy crashes in the small hours, for the third week in a row, we won't risk running out of data files to split... ;-)

Thinking on this event, I already reserve a place in my favorite bar for tomorrow. LOL

There are people who are willing to set their hair on fire and howl at the moon if necessary.

I cannot contribute to the hair fire, so I will go to the bar with Juan.

The fetid stench of burnt hair and the dissonant sounds of howling at the moon most likely would cause many to drink.

---

more data points.
at 0:20 we had 2645 channels left.
at 5:40 we had 2357 channels left.
The crunch rate has slowed. we are now doing about 1296 channels / day. according to these latest data points now that we are into the blc11s, so we will be fine until Monday morning without added files.

The big question is... will we have another server issue this Sunday morning (10:30 to 11:30 UTC best guess) ?? If so, what cron job is triggering this?? I hope I wake to find the machine working well despite the predictions of a problem.

more data points.
at 0:20 we had 2645 channels left.
at 5:40 we had 2357 channels left.
The crunch rate has slowed.

Actually, it's picked up, then dropped down a bit, but is likely to pick up again.
Some of those BLC11s take about 25% less time to process than the BLC34s did.

---

Grant
Darwin NT

Looks like it is deja vu all over again

9/22/2019 5:48:38 AM | SETI@home | Scheduler request failed: Couldn't connect to server
9/22/2019 5:48:39 AM | | Project communication failed: attempting access to reference site
9/22/2019 5:48:40 AM | | Internet access OK - project servers may be temporarily down.

---

Yup. I wasn't watching at the time, but my first logged failures are

22/09/2019 11:40:11 | SETI@home | Scheduler request failed: Timeout was reached
22/09/2019 11:42:08 | SETI@home | Scheduler request failed: Couldn't connect to server

(tz UTC+1)

Edit: and last successful on any machine was 10:34:17 UTC. "Once is a mistake. Twice is a pattern. Three times is a habit ..."

Looks like I missed our not scheduled but turning into a regular Sunday morning outage. Someone at Seti was up late, or up early to give us some more data too.

blc35_2bit_guppi_58643 *

Somebody is working on Sunday, they add a lot of blc35 tapes

One question: is only me, or the bls 34-35-36 tapes stresses a lot more the GPU'e while crunching?
I run on AIO hybrids but even with this I see an increase of few degrees on the GPU while they are crunching.

---

Somebody is working on Sunday, they add a lot of blc35 tapes

One question: is only me, or the bls 34-35-36 tapes stresses a lot more the GPU'e while crunching?
I run on AIO hybrids but even with this I see an increase of few degrees on the GPU while they are crunching.

See earlier in this thread. There's a big difference between the data recorded on day 58642 and that for day 58643 (I was trying to work out why). The new tapes are day 58643, so I'm expecting they'll be chewy.

Somebody is working on Sunday, they add a lot of blc35 tapes

One question: is only me, or the bls 34-35-36 tapes stresses a lot more the GPU'e while crunching?
I run on AIO hybrids but even with this I see an increase of few degrees on the GPU while they are crunching.

. . Most definitely yes, the temps are up and system response is poorer. Those little suckers really tie up the GPUs.

Stephen

< shrug >

results received per hour is up to 134k, which is a little higher than usual, so I was wondering how the new data is??

results received per hour is up to 134k, which is a little higher than usual, so I was wondering how the new data is??

Bumped a few of the early arrivals to see how they ran. Seem, as expected, to be of the longer-running variety, like the recent BLC34s.

results received per hour is up to 134k, which is a little higher than usual, so I was wondering how the new data is??

. . I am seeing a few noise bombs.

Stephen

:(

We got some new data files blc34_2bit_guppi_58642*

They also gave us some Aricebo files to split this morning as well.

Plenty of data!! yeah!

That wasn't bad for a Tuesday outage.

They seem to be still finding old Aricebo files for us to run/rerun (Multibeam only not AP
21jn12ac

That wasn't bad for a Tuesday outage.

They seem to be still finding old Aricebo files for us to run/rerun (Multibeam only not AP
21jn12ac

. . It seems they are still cleaning out the closet :)

Stephen

:)

What's up with the data?? We are having a hard time recovering from the outage and building up a nice RTS queue. the results returned is a little high at 145k. The deletions are a bit high, which is probably what is causing the splitters to be slow.

I'm guessing everyone has a good cache, so as long as the current data isn't too noisy we should get back to normal soon enough.

What's up with the data?? We are having a hard time recovering from the outage and building up a nice RTS queue. the results returned is a little high at 145k. The deletions are a bit high, which is probably what is causing the splitters to be slow.

I'm guessing everyone has a good cache, so as long as the current data isn't too noisy we should get back to normal soon enough.

Yes both of my rigs had recovered full caches by the time I got up this morning (10hrs ago), but a lot of the current Arecibo MB work is either VHAR or VLAR noise bombs from what has landed here so far which might account for that.

Cheers.

What's up with the data?? We are having a hard time recovering from the outage and building up a nice RTS queue. the results returned is a little high at 145k. The deletions are a bit high, which is probably what is causing the splitters to be slow.

I'm guessing everyone has a good cache, so as long as the current data isn't too noisy we should get back to normal soon enough.

. . It's not that they are noisy but rather that they are quickies. These Blc34 tasks take about half the time that the Blc35s were taking :) Part of that is because a large number of them are not actually VLAR tasks.

. . So returns are high, RTS is low and there is a backlog building up at the deleters.

Stephen

:)

The 21jn12ac tasks are VHAR's and quickies.

---

Seti@Home classic workunits:20,676 CPU time:74,226 hours

A proud member of the OFA (Old Farts Association)