And when the server processes are stopped and restarted - say for Tuesday maintenance - the splitters appear to start working on the most recently loaded batch, rather than resuming older batches.

not at all, they're working on the smallest number of blc*

Within each batch, yes. But you need to be aware of when each collection of 'tapes' started to appear on the page: the partially-split blc7 tapes have been there the longest, and the partially-split blc5 tapes have been there less long. The active blc3 tapes are the most recent arrivals. A one-time glance at the SSP isn't enough to give you the full picture.

(I must get out more...)

Interesting arrival of a bunch of small MESSIER031 tapes on the SSP. I imagine I won't have to worry about those at least until the morning.

Interesting arrival of a bunch of small MESSIER031 tapes on the SSP. I imagine I won't have to worry about those at least until the morning.

Seems to be from observations a day or two earlier than all those MESSIER031 files we got back in April. This group is all from the 57396 date, while all the ones in that first "messy" group were either 57397 or 57398. I wonder if these will be just as noisy or if they've tried cleaning them up at all before splitting them.

Interesting arrival of a bunch of small MESSIER031 tapes on the SSP. I imagine I won't have to worry about those at least until the morning.

Seems to be from observations a day or two earlier than all those MESSIER031 files we got back in April. This group is all from the 57396 date, while all the ones in that first "messy" group were either 57397 or 57398. I wonder if these will be just as noisy or if they've tried cleaning them up at all before splitting them.

If they are noisy we will burn through them reasonably quickly. I am assuming by noisy you mean tasks that run fast?

---

If they are noisy we will burn through them reasonably quickly. I am assuming by noisy you mean tasks that run fast?

Yeah, I think about 70% of them resulted in -9 overflows. I remember posting the following at the time:

Was just checking my machines before I went to bed and watched one blow through 7 consecutive messier031 tasks in 41 seconds.

They weren't VLARs, either, so even if they weren't overflows, the NVIDIA GPUs handled them just fine, IIRC.

I wonder if these will be just as noisy or if they've tried cleaning them up at all before splitting them.

This combining with different AR than BLC ones could mean not correctly chosen thresholds for such GBT data...
If new bunch will have excessive noise too worth to attract Eric attention to this issue.

---

SETI apps news
We're not gonna fight them. We're gonna transcend them.

Where did we go?

---

Third door on the left, the invisible one without a handle or name plate....

---

Bob Smith
Member of Seti PIPPS (Pluto is a Planet Protest Society)
Somewhere in the (un)known Universe?

So it looks like seti is reporting negative credits to free DC and BoincStats.

Anyone else seeing this? Is this related to outage the other day?

So it looks like seti is reporting negative credits to free DC and BoincStats.

Anyone else seeing this? Is this related to outage the other day?

BOINC projects don't export stats 'to' anywhere at all: they just make the data available at a public place, and say "come and get them" - so if two different sites show the same problem, it's a sure guess that there's something wrong with the exported data, rather than the stats sites' interpretation of them.

In our case, the public place is

http://setiathome.berkeley.edu/stats/

Looking at the 12 August version of those files, there's something wrong with tables.xml - there should be summary lines for users, hosts, teams and project total credit at the top, under the 'update time'.

The server status page was also squiffy for a while after the server outage, and I'm guessing you're right - they are related. Also note that the replica database is currently about 25K seconds behind the master, which can affect values too.

I'd suggest we wait and see if the files return to normal today or tomorrow, and drop a note to the staff on Monday if they're still out of kilter.

Cool, thanks Richard

I'd suggest we wait and see if the files return to normal today or tomorrow, and drop a note to the staff on Monday if they're still out of kilter.

Hopefully files do get fixed before SETI@Home Wow Event 2016 starts Monday 16.00 UTC...

I'd suggest we wait and see if the files return to normal today or tomorrow, and drop a note to the staff on Monday if they're still out of kilter.

Hopefully files do get fixed before SETI@Home Wow Event 2016 starts Monday 16.00 UTC...

The Wow stats are updated hourly, so they must use a different source from the public dump, which is only updated once every 24 hours.

I'm wondering how long those 71 MBv7 results are going to be waiting for DB purging. Normally, they stick around for ~24 hours after being assimilated, but it's been a few days now.

---

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

Looks like BOINCstats is finding some new credits in today's dump, but we won't see the full picture until tomorrow's 'daily update' is complete.

I'd suggest we wait and see if the files return to normal today or tomorrow, and drop a note to the staff on Monday if they're still out of kilter.

Hopefully files do get fixed before SETI@Home Wow Event 2016 starts Monday 16.00 UTC...

The Wow stats are updated hourly, so they must use a different source from the public dump, which is only updated once every 24 hours.

I think they are scanning the actual account pages for the participants.

---

I did notice the negative credit in BOINCStats and I wonder if it's related to a situation I've been experiencing since at least about 21:00 UTC on 13th August. From my home network I have had no access to S@h - or anywhere else on berkeley.edu for that matter. But checking at my parents' place that same day (about 02:00 UTC 14th August) and also at my work office just now (20:00 UTC 14th August), I see no issues with berkeley.edu so I'm wondering if there's some routing problem somewhere between my home network and Berkeley.

Just to be clear, I have no other Internet issues on my home network and even gave the router a restart to get a fresh connection with my ISP. Am I really the only one with this issue?

---

Soli Deo Gloria

No problems here at my different locations. Might want to your antivirus program and make sure it isn't blocking your access

You might want to do a traceroute to the Seti servers.

http://boinc2.ssl.berkeley.edu
http://georgem.ssl.berkeley.edu
http://vader.ssl.berkeley.edu

You might also add them to your allowed URL "whitelist" in your AV program. I was getting download errors in mine till I whitelisted the servers for Seti and Einstein.

---

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

A proud member of the OFA (Old Farts Association)

The issue is at the network level, so I really doubt anti-virus is involved. Access is blocked to all services on berkeley.edu across all devices on my home network - Windows and Linux.

I did try a traceroute last night (at home) but I was using an on-line service (which was successful) and didn't think to try it from one of my computers. I'll try that when I get home.

---

Soli Deo Gloria