Did I state that life originated in the Galactic Center?? No I did not. I simply state any advanced civilization would use the massive amounts of energy available there. They might have evolved somewhere else out on the galactic arms, safe from all the star creation and destruction, like we have in our little backwater of the galaxy. But then their star would likely have grown to red giant state and they would have moved to someplace more hospitable and made use of the free energy near the GC.

---

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

A proud member of the OFA (Old Farts Association)

. . Hi,

. . I think this tells a story of what we are up against. This user looks like they did 'the right thing', when deciding to quit S@H on 19th March they aborted all their work, somewhere between 240 and 300 tasks I am guessing, maybe more because there are still 240 showing. But they seem to have 17,500 (roughly) ghosted tasks. Since they are no longer reporting to the servers the auto-ghost resend mechanism will not work. A shame they had not checked their stats earlier than their decision to leave, it might have taken just one ghost recovery attempt, because most of their ghosts would have simply 'expired'.

Stephen

:(

If line of sight is established, the angle is irrelevant. Even a few thousand miles is irrelevant on the scale we are interrogating.

There never WAS any line of sight to the GC from Arecibo. The telescope cannot observe anything that low on the horizon. It has an aperture angle of only 70°. Sagittarius is much closer to the southern horizon and is not in line of sight by the telescope.

No further point of discussion.

---

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

A proud member of the OFA (Old Farts Association)

Parkes would have been the preferred radio telescope for Sgr A*.

and any space based array would be the more optimal solution again.

. . The things about looking towards the centre of the Galaxy is that there is a lot more of the Galaxy to be seen than out here on the fringe. There is a helluva lot of real estate to monitor between here and the actual Galactic centre. I guess if YOU were on a mission at the edge of the Arctic ice cap wanting to communicate with other people you would aim your dish at the North pole rather than say, London?

. . Oh, and one other very critical fact. We HAVE Parkes and have had for many decades. So when are you going to build these off world radio telescopes?

Stephen

:(

You're absolutely correct. There is a lot of real estate between here and there, and phenomenally much more in the bands. I've already outlined the belief there was a pulsar in or near the center of the galaxy, and that might even be responsible for life in the outer bands as some theories suggest. The gasses that was blown from the center might well be what fueled life in the bands, and it is currently starving the Milky Way as well. That same pulsar activity, and the extreme magnetic activity, doesn't bode well for life there. I think the chances of finding life are far more likely in the bands. That doesn't mean the posts in the south are useless, they're not. It is just a lot less likely, Theories being what they are, and science what it is, are often wrong, so all alternatives should continue to be examined. I just can't see it as a more viable option that other listening posts. I'm game, I'll crunch the numbers for the southern listening post, I just don't see it as the most important area to interrogate. I've already stated that a space based listening post is far on the time horizon. I just believe it is a lot more important, not to mention we would have a much longer baseline for these arrays, meaning a lot more definition, and a lot more sensitive, and big deal here is we can optimize such an array for every conceivable possibility, including looking through much of the activity near the center. We'll be long gone from the earth before this actually gets any traction.

Did I state that life originated in the Galactic Center?? No I did not. I simply state any advanced civilization would use the massive amounts of energy available there. They might have evolved somewhere else out on the galactic arms, safe from all the star creation and destruction, like we have in our little backwater of the galaxy. But then their star would likely have grown to red giant state and they would have moved to someplace more hospitable and made use of the free energy near the GC.

Anything is possible, that's why we should never stop doing what we do. I just see the likelihood of finding life there as actually diminished. There is a lot of energy all through the galaxy, and it is a lot more safe away from the center where there is extreme magnetism, extreme radiation, extreme violence, and extreme gravitational pull. There has to be a balance for life to remain, not just create. I see a lot more balance away from the center.

If line of sight is established, the angle is irrelevant. Even a few thousand miles is irrelevant on the scale we are interrogating.

There never WAS any line of sight to the GC from Arecibo. The telescope cannot observe anything that low on the horizon. It has an aperture angle of only 70°. Sagittarius is much closer to the southern horizon and is not in line of sight by the telescope.

No further point of discussion.

Nice misdirection. LOS was in reference to space based, not land based, observation. And this point is really a who cares. Sgr A should never be the target of listening anyway. You're not going to find life there.

Host 8906296 is an interesting case study. Joined project on 24 February, got one allocation of at least 27 tasks, and has never been heard of again. We were sending out BLC work then, so most of the tasks had the same deadline - and they timed out this morning. 26 errors, and I got most of them. They won't be visible for long - they hit a fast machine, and they've all been processed before the half-hour backoff expires.

I wonder why the people who quit are not detaching from the project. What I have read from the scheduler source suggests that doing that would release all the work to be sent to others. Ghosts too.

Where did you read that? My understanding was that the client did a local reset on the project (which deletes all local files) before detaching, but didn't even attempt to communicate with the project - so it wouldn't help if they did do a formal 'detach'.

I think it more likely that they simply uninstall BOINC (don't like the fan noise, perhaps - that one looks like a notebook) without any understanding of the processes involved. I'll look at the code again myself.

I wonder why the people who quit are not detaching from the project. What I have read from the scheduler source suggests that doing that would release all the work to be sent to others. Ghosts too.

. . That would make it a good practice but I am guessing no-one passed that knowledge on to the rank and file volunteers, I had certainly not heard it before though it does make perfect sense.

Stephen

. .

Where did you read that? My understanding was that the client did a local reset on the project (which deletes all local files) before detaching, but didn't even attempt to communicate with the project - so it wouldn't help if they did do a formal 'detach'.

Function mark_results_over() in sched/handle_request.cpp. The comment in front of the function definition says

// Called when there's evidence that the host has detached.
// Mark in-progress results for the given host
// as server state OVER, outcome CLIENT_DETACHED.
// This serves two purposes:
// 1) make sure we don't resend these results to the host
//    (they may be the reason the user detached)
// 2) trigger the generation of new results for these WUs
//

. . That would make it a good practice but I am guessing no-one passed that knowledge on to the rank and file volunteers, I had certainly not heard it before though it does make perfect sense.

I have always considered the source code of open source software as part of the documentation ;)

. . That would make it a good practice but I am guessing no-one passed that knowledge on to the rank and file volunteers, I had certainly not heard it before though it does make perfect sense.

I have always considered the source code of open source software as part of the documentation ;)

. . Then you have more patience than I do. Apart from the headache trying to understand it. Though embedded comments that like the one you quoted sure do help.

Stephen

. .

There's your problem - the code is run inside 'handle_request.cpp'.

These hosts aren't sending a request RPC to the server, ever. There's never any evidence (except silence) that a client has detached. The code is, in reality, triggered when cheating is detected - two different hosts are running with the same HostID number (to double RAC, perhaps, or someone is cloning an account to save time): then the <rpc_seqno> gets out of step and the server allocates a new HostID to one of the clones.

(My wingmate this morning is still showing "Last contact 24 Feb 2020". Absence of evidence is not evidence of absence)

I'm a C coder, so C++ is quite a bit harder for me to read. But Boinc source despite being C++ is actually closer to plain C. Boinc is doing the C way lot of the things that are normally done differently in C and C++.

There's your problem - the code is run inside 'handle_request.cpp'.

These hosts aren't sending a request RPC to the server, ever. There's never any evidence (except silence) that a client has detached.

So when you detach, the client is not contacting the scheduler to tell "Hey I'm detaching"?

Edit: looks like it is not and also looks like this is not intentional. Detaching specifically triggers a scheduler request to be done as soon as possible but it also removes the project before it can be done so there is no project to contact.

There's your problem - the code is run inside 'handle_request.cpp'.

These hosts aren't sending a request RPC to the server, ever. There's never any evidence (except silence) that a client has detached.

So when you detach, the client is not contacting the scheduler to tell "Hey I'm detaching"?

Edit: looks like it is not and also looks like this is not intentional. Detaching specifically triggers a scheduler request to be done as soon as possible but it also removes the project before it can be done so there is no project to contact.

That's the sort of thing it would be good to write up at https://github.com/BOINC/boinc, as a new issue.

On second thoughts - are you sure?

static void handle_project_detach(GUI_RPC_CONN& grc) {
    PROJECT* p = get_project_parse(grc);
...
    gstate.detach_project(p);
    gstate.request_schedule_cpus("project detached by user");
    gstate.request_work_fetch("project detached by user");
    grc.mfout.printf("<success/>\n");
}

The lines after the 'detach' don't initialise an RPC to -this- project: they trigger the polling loop to check if the -remaining- projects on the host need to react to the loss of this project and its work (if any).

Edit - also see https://github.com/BOINC/boinc/blob/master/client/client_state.cpp#L2109:

// "Detach" a project:
// - Reset (see above)
// - delete all file infos
// - delete account file
// - delete project directory
// - delete various per-project files

No mention of telling the project what's going on.

Results out in the field 1,998,795 As of 16 Apr 2020, 10:40:04 UTC

Results out in the field 1,900,221 As of 17 Apr 2020, 14:00:04 UTC
Results out in the field 1,899,542 As of 17 Apr 2020, 14:10:03 UTC

So it's taken around 27 hours to return 100,000

What the meow???

Data Distribution State SETI@home v7 # Astropulse # SETI@home v8 # As of*
Results ready to send 0 972 37,039 0m
Current result creation rate ** 0/sec 12.7438/sec 339.5035/sec 5m
Results out in the field 0 12,939 1,984,825 0m

False data? Or what?

Meow?

---

"Freedom is just Chaos, with better lighting." Alan Dean Foster