There was also a shorty AO tape from yesterday 05Feb18 loaded briefly

The Arecibo data from the observation run Saturday is paying out nicely, like the Arecibo data of old.

Task 2848185979

Run time 1 hours 52 min 23 sec
CPU time 1 hours 50 min 22 sec
Validate state Valid
Credit 104.63

. . I wish I could say the same, most of the limited Arecibo work I am getting is on GPUs and is getting scores more like the GBT work. An occasional task will rise to the rarefied heights of high seventies. Aint technology wonderful .....

Stephen

:(

Yes, I would say those few tasks that were awarded in the 100's are displaying the symptom I have seen before. Any new work dispensed for the first time to the first crunchers gets awarded higher credit. It is like the scheduler and assimilators need to train the credit award mechanism for the first tasks returned and award higher than the normal long-term credit.

My later Arecibo tasks were awarded the same as yours, mid 70-80's.

---

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

A proud member of the OFA (Old Farts Association)

. . I wish I could say the same, most of the limited Arecibo work I am getting is on GPUs and is getting scores more like the GBT work. An occasional task will rise to the rarefied heights of high seventies. Aint technology wonderful .....

Stephen

:(

When I filled my cache about 14 else to go I only got GBT data good on you if you are getting work from Arecibo

---

. . I wish I could say the same, most of the limited Arecibo work I am getting is on GPUs and is getting scores more like the GBT work. An occasional task will rise to the rarefied heights of high seventies. Aint technology wonderful .....

Stephen

:(

When I filled my cache about 14 else to go I only got GBT data good on you if you are getting work from Arecibo

. . They got in a couple (or 3) new tapes from Arecibo and split them over the weekend, there was relatively little work generated overall but many of us crunchers were lucky enough to score a few of them. They are now long gone but for me they included several (less than 6) VLAR tasks and a handful more of normal AR units. Sorry if you didn't see any of them, it was a bit of a lucky dip really. Now it is back to chewing on older GBT WUs.

. . You have to laugh. Having written that I just checked my Q's over 3 machines and I have 6 old 2007 resends, 2 VLARs and 4 normals, but that is out of 520 tasks. Oh, and 5 APs that have been sitting on the one machine since the weekend because they will not run on it despite my efforts to get them to. But at the most they only ever represented a very small percentage of the work I was getting.

Stephen

:(

I think I was the very first person to pull the newly loaded Arecibo tape from the RTS buffer on Monday. I think I scored somewhere around 140 Arecibo tasks. The first ones paid out like in olden dayz.

---

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

A proud member of the OFA (Old Farts Association)

Well this pack of WUs are paying an average of around 75 credits each despite running steadily 24/7.......credit screw is very discouraging.

---

"Sour Grapes make a bitter Whine." <(0)>

. . and I was interested to see that they are Voyager1 related ...

Regarding those intriguing gbt bl VOYAGER1 files, this page explains to anyone interested why and how previous similar telemetric data was dealt with.

Breakthrough Listen: Voyager 1 Observations

Voyager 1 is the most distant man-made object from Earth. Launched by NASA in 1977, it has travelled at fantastic speed (roughly 17,000 m/s), past the outer boundaries of our Solar System and into interstellar space (>12.5 billion miles from the Sun).

Remarkably, 38 years on, Voyager 1 is still sending telemetry data from the depths of interstellar space. This makes it a great systems test for the Breakthrough Listen signal processing pipeline.

In this tutorial, we load, read, and plot some Breakthrough Listen (BL) observations of Voyager 1

(...)

If you've gotten this far, take a moment to pause and reflect. This faint signal has travelled billions of miles through space, back to us here on Earth. Launching this probe out of the Solar System was an immense feat, and the fact that we can detect it still, almost 40 years after its launch, is even more impressive.

The signals from probes such as Voyager are very different from the signals we measure from astrophysical objects. This is one of the approaches Breakthrough Listen is using in its approach toward detecting extraterrestrial signals.

End of the parenthesis, and now returning to the regular programming =:)

---

Apr 3, 1999 - May 3, 2020

Well this pack of WUs are paying an average of around 75 credits each despite running steadily 24/7.......credit screw is very discouraging.

. . I am tending towards the theory that CreditScrew is an Anarchist plot to erode the number of volunteers crunching for SETI.

. . It's a good thing many/most of us are here for the comeraderie :)

. . OK, so mostly we are here because we hope to find some little green men ... :)

Stephen

:)

. . I am tending towards the theory that CreditScrew is an Anarchist plot to erode the number of volunteers crunching for SETI.

It would certainly help reduce the server load if the number of active users dropped by 50%

---

Grant
Darwin NT

If the "active" users were heavy-duty crunchers, maybe no difference in project throughput.

---

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

A proud member of the OFA (Old Farts Association)

If the "active" users were heavy-duty crunchers, maybe no difference in project throughput.

Yep.
If would depend on how much the top 2% of active users contribute to the total Returned-per-hour number.

---

Grant
Darwin NT

Hmmm.
The daily glitch appears to have moved about 45min to an hour later.

---

Grant
Darwin NT

Seems like it hits here at the same time. Just posted in the lounge the site went dark and no connections were going through. Notice at Haveland they just dumped a boatload of wu deletions.

---

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

A proud member of the OFA (Old Farts Association)

Seems like it hits here at the same time. Just posted in the lounge the site went dark and no connections were going through. Notice at Haveland they just dumped a boatload of wu deletions.

. . Well looking at the tapes splitting it looks like being a dry old weekend ...

Stephen

:(

I've been seeing the servers get tied in knots lately every night when I get home at midnight CST.
Hard to contact the servers or the forum pages at all.

---

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

I found it strange when Grant mentioned he believe the project communications strangeness happened 45 minutes earlier than normal and for me it was exactly the same.

For me the project becomes unreachable or slow at 11:30 - 12:00 Midnight PST every night. That points to something locally happening at each of our locations since we are in very different time zones.

---

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

A proud member of the OFA (Old Farts Association)

. . Well looking at the tapes splitting it looks like being a dry old weekend ...

Stephen

:(

Looks like they added a bit more data overnight. When I went to bed the splitters only had about 1250 channels left to do. Now the unsplit channels are over 2000.

We are going to need more than that though to make it through to Monday.

---

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

A proud member of the OFA (Old Farts Association)

BOINC permits users via their cc_config files to report all results immediately. That means many more, albeit much shorter, queries to the servers (as opposed to say an hourly update). Would restricting (or asking users not to use ) this setting help or hurt the server load issue? Could hourly updates be staggered by sorting users (maybe alphabetically by user name or some other criteria) to even our the server load? Just a thought.....

---

I found it strange when Grant mentioned he believe the project communications strangeness happened 45 minutes earlier than normal and for me it was exactly the same.

Later than usual.

On the Haveland graphs it used to be a bit after 06:00. The last couple of days it's been around 07:00.

---

Grant
Darwin NT

BOINC permits users via their cc_config files to report all results immediately. That means many more, albeit much shorter, queries to the servers (as opposed to say an hourly update). Would restricting (or asking users not to use ) this setting help or hurt the server load issue? Could hourly updates be staggered by sorting users (maybe alphabetically by user name or some other criteria) to even our the server load? Just a thought.....

Better to have things spread out over a 24 hour period than lots of short, sharp, heavy demands on the system.
Getting work after an outage can be difficult- having groups of people all trying to report & get work at the same time will be lots of such events throughout the day. Add to the fact that I have to limit the number of results I report at time, otherwise i get nothing but Scheduler errors after an outage means such a system would just lead to other problems. Lots of smaller Scheduler requests through out the day are better than lots of large ones at one time.

---

Grant
Darwin NT

I have to limit the number of results I report at time, otherwise i get nothing but Scheduler errors ...

Having a less verbose std_err report per task in the sched_request file might help with that one.