No acknowledgement from either Eric or Jeff as far as I know. Maybe they will attend to the issue on the outage tomorrow.

---

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

A proud member of the OFA (Old Farts Association)

Only a couple of machines here, but have had no "download problems" in the last 24 hours and I was getting them prior to that

Still getting massive backoffs on all hosts without constant nudging to clear at least some of the backlog.

---

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

A proud member of the OFA (Old Farts Association)

No problems here since midnight UTC that I've seen.

Cheers.

Got home to find instant timeout issues again.

Defaulted to GeorgeM for downloads, no more timeouts.

So I guess the question is- If after x number of failed attempts to download something, why don't affected systems get the other server to try? And why don't unaffected systems become affected, why are they always using the other server?


And I notice that that while the Deleters have caught up, the Assimilators are falling behind.

---

Grant
Darwin NT

wow, back already.

---

Seti@Home classic workunits: 29,492 CPU time: 134,419 hours

But they didn't fix the downloads issues.

---

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

A proud member of the OFA (Old Farts Association)

But they didn't fix the downloads issues.

No joy here as well.
Even a tiny worse. But it can be a fluctuation or probably the effect after the outage.

Serious panic time, the Haveland graphs are MIA.


Since editing the hosts file, no download issues.

---

Grant
Darwin NT

Yes, I noticed the Haveland website was down several hours ago.

I changed my hosts file and it made no difference. Changed it back and it made no difference. Ho hum.

[Edit] I see that Haveland graphs are back now.

---

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

A proud member of the OFA (Old Farts Association)

No Panic. Just some thoughts on the datafiles. I should probably create a separate thread for chatting about the datafiles.

I decided to compare the Aricebo files we have at this moment to Richard's great list.
15ap10ab and 15fe09ac

It looks like we have run these datafiles before, which might be why they aren't splitting APs on them. The only reason I could come up with for rerunning data would be an updated MP application, or a double check of something interesting in the data.

You are correct - once the APs have been split from a tape then they aren't re-split if the tape is reloaded. There has been no significant changes to the basic AP algorithm for quite a few years, and if a tape is heavily radar blanked, or very noisy the AP algorithm won't get anything extra out of it now than it did when the tape was first split.

---

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

A while ago I found the uploads stalled on my biggest AMD box.
It was displaying "downloads active" but nothing was moving. I re-tried the "backed off" ones at the bottom of the list and it apparently unlocked everything. Finished the uploads and then started downloading.

Tom

---

A proud member of the OFA (Old Farts Association).

No Panic. Just some thoughts on the datafiles. I should probably create a separate thread for chatting about the datafiles.

I decided to compare the Aricebo files we have at this moment to Richard's great list.
15ap10ab and 15fe09ac

It looks like we have run these datafiles before, which might be why they aren't splitting APs on them. The only reason I could come up with for rerunning data would be an updated MP application, or a double check of something interesting in the data.

. . This may be a continuation of Eric's clean sweep operation to pick up the old files that had issues and fell through the cracks. It may have been a series that had issues splitting or being crunched and was shelved before completion. Also when it was processed previously it was probably in the old 2 bit format not the current 4 bit format ( remember when the WU files increased from 357KB to 705KB ? ) so I don't find it of any concern at the moment. It may be that there was something interesting to re-examine but that would mean it had been through the back end process of 'nitpicker' or 'nebula' to find something. Seems less likely. Sadly :(

Stephen

:)

The bitness of the old process doesn't come into it - we haven't re-processed all the old files. It is more likely to be that they were only partially processed last time round.

---

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

The bitness of the old process doesn't come into it - we haven't re-processed all the old files. It is more likely to be that they were only partially processed last time round.

. . I think you misread my message. I was saying that Eric's clean up program was the probable cause. I mentioned the change to 4 bit format because someone had commented that there had been no change in MB crunching since these files were new, but there has. The 4 bit format gives slightly higher resolution results. I was not saying that this change was the reason for re-processing old files or we would have a landslide of old Arecibo tapes, though some people would love the higher RACs that this would bring :)

Stephen

:)

The bitness of the old process doesn't come into it - we haven't re-processed all the old files. It is more likely to be that they were only partially processed last time round.

. . I think you misread my message. I was saying that Eric's clean up program was the probable cause. I mentioned the change to 4 bit format because someone had commented that there had been no change in MB crunching since these files were new, but there has. The 4 bit format gives slightly higher resolution results. I was not saying that this change was the reason for re-processing old files or we would have a landslide of old Arecibo tapes, though some people would love the higher RACs that this would bring :)

Stephen

:)

Stephen as far as I am aware they tested 4 bit work units over at beta however this never got rolled out to main something to do with the amount of bandwidth required. please refer to the task name below.

blc35_[b]2bit[/b]_guppi_58406_19697_3C48_0082.23344.0.22.45.8.vlar_0 Received	(by server) 27 Apr 2019, 22:58:03 UTC

---

Stephen as far as I am aware they tested 4 bit work units over at beta however this never got rolled out to main something to do with the amount of bandwidth required. please refer to the task name below.

blc35_[b]2bit[/b]_guppi_58406_19697_3C48_0082.23344.0.22.45.8.vlar_0 Received	(by server) 27 Apr 2019, 22:58:03 UTC

. . I am sorry but that is wrong, clearly you missed the change. They rolled out the 4 bit versions over a year ago, without changing the naming format, and since then tasks have all been 700KB rather than the previous 357KB because of it. But that is what it is. Since we have yet to see any final results we have yet to see the benefit of that change, but I look forward to when we do.

Stephen

:)

. . I am sorry but that is wrong, clearly you missed the change. They rolled out the 4 bit versions over a year ago, without changing the naming format, and since then tasks have all been 700KB rather than the previous 357KB because of it. But that is what it is. Since we have yet to see any final results we have yet to see the benefit of that change, but I look forward to when we do.

Stephen

:)

Stephen please have a read on the following thread . As far as I am aware we are still processing 2 bit work units. You could be right but going off the latest post in thread I have linked to I still believe we are using the old format. I completely believe you about 700 kilobyte. If we are processing 4 bit tasks it is incredibly misleading.
Have a great weekend

---

As far as I am aware we are still processing 2 bit work units.

They've been 4bit WUs for at least 2.5 years. The larger WU file size was the result of that change.

---

Grant
Darwin NT