I am just hoping that IT gets to the root of the comms problem and they don't have to keep bouncing batches of work off the cloud to get it to the splitters.
If not, it was a rather creative way to do it.
Maybe that process could be automated if necessary.
Of course, the scientific view would be that the extra transfer diminishes the integrity of the data. Chain of possession.

. . That is a concern for me as well. Different file handling systems can add header info to files and perhaps affect the integrity of the data.

Stephen

? ?

Do you have "receive other tasks" tagged?

take a look:
http://nsa39.casimages.com/img/2018/01/31/180131073958773848.jpg
http://nsa39.casimages.com/img/2018/01/31/18013107434566643.jpg

now, last update here > 31-Jan-2018 19:10:27 [SETI@home] Scheduler request completed: got 110 new tasks

http://setiathome.berkeley.edu/results.php?hostid=7019416&offset=0&show_names=0&state=1&appid=

État: Tous (302) · En cours (200) · Validation en attente (46) · Validation non concluante (0) · Valide (56) · Invalide (0) · Erreur (0)

Application: All (302) · AstroPulse v7 (0) · SETI@home v8 (302)

about 99 CPU and 98 GPU

Home location for downloading Seti MB tasks and once done,
set on default location waiting AP task

---

Are you sure your computer "Location" (Needs translation, LOL) matches that for which the CPU tasks are disabled?
Other locations have it turned on.

Yes, for me the upload server at Main isn't available. All uploads in backoff.

---

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

A proud member of the OFA (Old Farts Association)

It looks like the Berkeley DNS Server just died...again.
I had one machine backing up until I added the DNS lines to etc/hosts;
208.68.240.118 setiboincdata.ssl.berkeley.edu
208.68.240.119 boinc2.ssl.berkeley.edu
208.68.240.126 setiboinc.ssl.berkeley.edu

That solved the backup.

Yes, for me the upload server at Main isn't available. All uploads in backoff.

31/01/2018 22:28:12 | SETI@home | [http] [ID#17001] Info:  Could not resolve host: setiboincdata.ssl.berkeley.edu

i.e. a DNS breakage. Wait, or activate hosts.

Edit: Yup, hosts fixed the upload. Then it couldn't report - same problem. Uncommented scheduler - that shifted it. Methinks they're fiddling in the server closet...

I concur. Uncommented the servers in the hosts file and now can upload.

---

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

A proud member of the OFA (Old Farts Association)

Yes, for me the upload server at Main isn't available. All uploads in backoff.

Ah, I didn't notice that, since I don't do Main. Not good, let's hope it isn't anything seriously wrong, with both Main and Beta.
Too much downtime recently.

Maybe some action on the part of campus networking trying to solve their Green Bank data connection problem.

---

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

A proud member of the OFA (Old Farts Association)

To be brutally honest, I've all but given-up on this.

---

Don't take life too seriously, as you'll never come out of it alive!

My untweaked hosts (running with normal DNS) have just uploaded and reported - back to normal. I've got enough to last until morning, so I'm not bothering to download - untested.

(actually, my browser report on Beta was 'unable to find IP address' - DNS again. And I think DNS is under the control of the Space Science Laboratory, not SETI or the co-lo. SSL were messing with mailing lists this morning - blame them, for a change ;-))

I advocated exactly that, back in mid December 2017 or so.

---

Don't take life too seriously, as you'll never come out of it alive!

Are you sure your computer "Location" (Needs translation, LOL) matches that for which the CPU tasks are disabled?
Other locations have it turned on.

hi, i believe that i'm undestanding these settings like :

in Default or Work parameters:
for only AP app, use CPU and GPU 10 days cache ( 1 CPU AP / day ( +24h to crunch it ) , a lot of more for GPU ) no work for other app ( MB )
in Home parameters:
for MB or AP app, Use only GPU 1day cache

am i right ?

---

To be brutally honest, I've all but given-up on this.

. . Try not to be disheartened. I know all the downtime, problems, unscheduled outages etc are demoralising but think how exciting it will be if/when they find an ET signal? :)

Stephen

:)

To be brutally honest, I've all but given-up on this.

Yup, SETI@Home nowadays, is like an old rusty, rattling VW beetle from the 1950's.
It either needs to be scrapped, or go through a long an expensive renovation.

Just one persons opinion.

Shut it down and take as much time as iis needed to fix the problem.

I agree Clyde. Shut it down totally, and fix it before coming back again.
Be that for a month, six months, or a year.

. . You must be young ... I am too old to wait a year :)

Stephen

???

To be brutally honest, I've all but given-up on this.

I must say your RAC pants a completely different picture. I have a slightly off topic question how many tasks are you running on your 970? I am only running one when I crunch for this project. End of off topic

---

One task at a time on the 970 - I reckon that it earns a short, cooling, break after each task!

---

Don't take life too seriously, as you'll never come out of it alive!

One task at a time on the 970 - I reckon that it earns a short, cooling, break after each task!

Thanks for your feedback. Do you give it a break by suspending all tasks in the queue and individually letting each task run?

---

So wasn't the cpu cache or slowest hardware supposed to get filled first? Or do I have that backwards?

I don't know what's supposed to happen, but it's always been the faster processor that gets work first.

Yes, it was fastest device first IIRC.
Now my CPU is the fastest device but i always get work for GPU first.

Runt times for your CPU are still way longer than the GPU. I figure it bases it's dishing out of work based on APR values (ie per WU processing time).

---

Grant
Darwin NT

One task at a time on the 970 - I reckon that it earns a short, cooling, break after each task!

Thanks for your feedback. Do you give it a break by suspending all tasks in the queue and individually letting each task run?

No need.
It takes roughly 15-20seconds after 1 SoG WU finishes before the next WU starts running on the GPU. That initial period is some pre-processing on the CPU.

---

Grant
Darwin NT

in Default or Work parameters:
for only AP app, use CPU and GPU 10 days cache ( 1 CPU AP / day ( +24h to crunch it ) , a lot of more for GPU ) no work for other app ( MB )
in Home parameters:
for MB or AP app, Use only GPU 1day cache

am i right ?

Yes, but are you sure that you have selected that specific Location on that particular computer?

---

Grant
Darwin NT