Eric has commented on this. It's in the NEWS section

https://setiathome.berkeley.edu/forum_thread.php?id=81903&postid=1888412

I remember crunching the larger work units on Beta last year. Didn't have any problems with them. Not seeing any issues now. Slightly longer time to crunch but that is about it.

---

Funny:
07/09/2017 20:12:55 | SETI@home | [http] [ID#21] Sent header to server: GET /sah/download_fanout/14e/blc04_2bit_blc04_guppi_57898_17342_DIAG_KIC8462852_0019.14226.818.17.26.149.vlar HTTP/1.1
...
07/09/2017 20:12:55 | SETI@home | [http] [ID#21] Sent header to server: This is not yet the full data set, which lives at Penn State, it's some test on-target/off-target observations that we're checking out.<br />

---

You get it by enabling the <http_debug> flag and it only happens on downloads of the KIC8462852 tasks.

---

Thanks for the link, checked it out, but that raises another question, one post seemed to indicate that they are bigger WU's but not necessarily taking significantly longer to process? I guess in the scheme of things, if we do better work but it doesn't take significantly longer, then it to me seems a partial win. Ideally I would think that they would require a bit more time on the crunching (our) end to help relieve the I/O issues. It looks to me from his post that the goal is better data, and that possibly longer crunching times would be an effect of it, but not the primary objective.

---

Hmm, with double the demand on the bandwidth, I really wonder if this is going to work?
I really doubt it.

. . Don't be a pessimist, think instead that maybe this improvement will make the difference that will find E.T.

Stephen

:)

I would imagine changing the time period for a task would cause quite a problem with the database storage and/or extraction/comparison of results. With the data units being the same size it is probably the best to keep it that way.

I'm certainly seeing download issues with doubling of file sizes and my 5Mb/s pipe. It does affect normal surfing much more than before.
I may have to try going back to 2 concurrent download per computer.

. . FWIW my rigs are running with just the 2 concurrent download setting and I am not seeing any dramatic change with the new format, I wouldn't have noticed it and hadn't until others pointed it out.

Stephen

:)

Thanks for the link, checked it out, but that raises another question, one post seemed to indicate that they are bigger WU's but not necessarily taking significantly longer to process? I guess in the scheme of things, if we do better work but it doesn't take significantly longer, then it to me seems a partial win. Ideally I would think that they would require a bit more time on the crunching (our) end to help relieve the I/O issues. It looks to me from his post that the goal is better data, and that possibly longer crunching times would be an effect of it, but not the primary objective.

. . These ar NOT "bigger work units", merely bigger files because they are providing 4 bits per data point and not the original 2 bits. For some this may strain their download bandwidth but from my experience in Beta any change in the run times will be barely noticeable. They will provide better analysis though and this IS a good thing.

Stephen

:)

Just tried to create some new preferences for another location (School, then tried Work). And all I get is the error below.
Unable to handle request
Link has timed out. Please click Back, refresh the page, and try again.

Follow the instructions, same error.

---

Grant
Darwin NT

Just tried to create some new preferences for another location (School, then tried Work). And all I get is the error below.
Unable to handle request
Link has timed out. Please click Back, refresh the page, and try again.

Follow the instructions, same error.

. . There have been some issues lately with the DN server (though this may not be due to that) ...

. . Have you tried adding the following lines to your hosts file (\Windows\system32\drivers\etc\hosts) ??

208.68.240.118 setiboincdata.ssl.berkeley.edu # upload server Jun 2017
208.68.240.119 boinc2.ssl.berkeley.edu # download server Jun 2017
208.68.240.126 setiboinc.ssl.berkeley.edu # scheduler Jun 2017

Stephen

??

Not a server problem per se, but I am too lazy to start my own thread.
Just found 10oc08af.4998.890.14.41.62_0 running for several minutes stuck at 0.02% progress. When it reached the estimated run time and went past that, the estimated time jumped to 130+ days. Ran out to 145 days, then the task ended. Still at 0.02% progress. We'll see if it validates.

---

Not a server problem per se, but I am too lazy to start my own thread.
Just found 10oc08af.4998.890.14.41.62_0 running for several minutes stuck at 0.02% progress. When it reached the estimated run time and went past that, the estimated time jumped to 130+ days. Ran out to 145 days, then the task ended. Still at 0.02% progress. We'll see if it validates.

Well, that's just typical Boinc madness, isn't it?

---

"Time is simply the mechanism that keeps everything from happening all at once."

Seti madness, Mark, Seti madness. :)

---

Seti madness, Mark, Seti madness. :)

LOL....plenty of that to go around, I guess.

---

"Time is simply the mechanism that keeps everything from happening all at once."

A whole bunch of BLC05 were loaded some time ago... should be interesting

---

A whole bunch of BLC05 were loaded some time ago... should be interesting

. . Define "interesting" !

Stephen

:)

Well you asked for them by naming them..lol

---

Well you asked for them by naming them..lol

. . Hmm true, but I didn't say their name three times :)

Stephen

:)

Web site went AWOL for a few minutes there, and the last Scheduler request timed out.

---

Grant
Darwin NT

Project back relatively early today. Hope that is a beginning of a trend.

---

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

A proud member of the OFA (Old Farts Association)

Web site went AWOL for a few minutes there, and the last Scheduler request timed out.

. . Also the servers went AWOL last night during the outage, all uploads failed to find the servers for quite a while, and since one of my rigs is still accessing the servers by their direct address (not DNS) then they were themselves unavailable.

Stephen

:(