OK, not using r540, I am using stock at the moment.

To receive Beta AP and not Beta V7, how should preferences be set ?

My guess:

SETI@home v7: no
Other applications: yes

For completeness, SETI@home Enhanced, Astropulse and Astropulse v5 all no - though you should only get the very occasional resend from those, anyway.

Joe did remind Eric that the page needs updating, but I guess Saturday overtime rates didn't extend to that...

And Eric probably just did it from his home computer anyway.

---

I had an urgent phone call not long back about a printer just down the road that suddenly stopped printing. I walked 4 doors down the road and seen the problem as soon as I walked in the room, the printer didn't have the USB cable connected to the PC (is that suppose to be plugged in? she said). :(

Cheers.

Computer service lesson number several thousand:

All computer cables have at least two ends.

(and at least two of them should always be plugged in)

OK, not using r540, I am using stock at the moment.

To receive Beta AP and not Beta V7, how should preferences be set ?

My guess:

SETI@home v7: no
Other applications: yes

For completeness, SETI@home Enhanced, Astropulse and Astropulse v5 all no - though you should only get the very occasional resend from those, anyway.

Joe did remind Eric that the page needs updating, but I guess Saturday overtime rates didn't extend to that...

Setting all to No, and ticking other apps will when updated set every boxes to yes :-)

So without a box for AP V6, how in heavens name should one know how to set the options to get only AP v6..

Hmm, hmm, hmm

Set Astropulse (the bare one, not the v5) to yes, and 'other apps' to yes, everything else to no.

That sticks, and - since there haven't been any v4 AP tasks for about three years - you shouldn't be inundated with unwanted work. But you can blame Eric if you are...

OK, not using r540, I am using stock at the moment.

To receive Beta AP and not Beta V7, how should preferences be set ?

My guess:

SETI@home v7: no
Other applications: yes

For completeness, SETI@home Enhanced, Astropulse and Astropulse v5 all no - though you should only get the very occasional resend from those, anyway.

Joe did remind Eric that the page needs updating, but I guess Saturday overtime rates didn't extend to that...

Setting all to No, and ticking other apps will when updated set every boxes to yes :-)

So without a box for AP V6, how in heavens name should one know how to set the options to get only AP v6..

Hmm, hmm, hmm

Set Astropulse (the bare one, not the v5) to yes, and 'other apps' to yes, everything else to no.

That sticks, and - since there haven't been any v4 AP tasks for about three years - you shouldn't be inundated with unwanted work. But you can blame Eric if you are...

Well, that didn't work, because the box "other apps" overrides the No for specific tasks. I just got an MB V7 even though that box was unticked.

If there are no AP V6 available the ticking of the other apps box, will send other apps if they are available, even if those apps are unticked. So a box for AP v6 is needed so one can untick the other apps box.

Edit: Same behaviour can be seen here on main. If you untick a specific application but tick the box for other apps, you will still get the app you unticked if there are no other apps available.

What we really need is explicit Yes No boxes for each app. So when you want to use the other apps box you can still filter things out.

---

SETI@home classic workunits: 93,865 CPU time: 863,447 hours
Join the [url=http://tinyurl.com/8y46zvu]BP6/VP6 User Group[

And Eric probably just did it from his home computer anyway.

No, still missing a box for Astropulse V6.

What I meant is he probably uploaded the new AP app to beta from home. Or at least turned it on in the options.

---

Things are still a bit iffy.
The resolution on the network graphs isn't that high, but instead of being smooth like it usually is, or jagged like it was when things were really acting up, the inbound traffic is looking rather squiggly for the last few hours.

---

Grant
Darwin NT

If I choose to send someone a Private Message, I am directed to my Inbox after posting.

Why not make this the account page instead?

It is not possible to allow only AP v6 tasks at Beta, but there are some things you might do to improve the odds. Since the beginning of AP v6 testing last December, when there's freshly-split AP a request in the "all applications" mode has gotten only AP tasks on my hosts. At other times I've gotten a mix, but it's clear that project isn't operating the same as here, there's almost always been at least 100000 SaH v7 tasks with lower resultIDs.

By a coincidental quirk, Sten-Arne's Q8200 system was assigned a task from the last AP WU which has been split: 3933033. The wingmate's host promptly errored its task, so for now there's an unsent reissue task for that WU. The splitters may start up again and produce WU 3933034 through 3933134 sometime soon. They seem to be configured to do a batch of 101 or so and there's that much remaining on the channel. OTOH sometimes they don't fire up automatically...

While the only available AP tasks are reissues, I think asking for a very small amount of work would help the odds of having AP v6 to do. That is, a small cache setting would get few SaH v7 tasks and go back again sooner with another chance to catch some AP v6.

=================

Lunatics Rev. 546 was the final change needed for compatibility with the AP Validator changes.

                                                                 Joe

Agree

---

Dave

By a coincidental quirk, Sten-Arne's Q8200 system was assigned a task from the last AP WU which has been split: 3933033. The wingmate's host promptly errored its task, so for now there's an unsent reissue task for that WU.

And the only thing that computer is doing, is erroring out every AP it gets. As usual, it's a Linux host getting the infamous "process got signal 11" error (SIGSEGV: segmentation violation).

Why the project continues to send out the app to Linux hosts is beyond me, when 90% of all Linux hosts are incapable of running AP's. As if we had an endless bandwith, the project just keep on sending out 8MB files to be trashed in seconds.

Nobody can make me do anything else than laugh, when they complain about bandwidth saturation, as long as I see this waste of the same bandwith, by sending out thousands of 8MB AP files to Linux hosts, just so they can trash them, and force a resend of the same 8MB file.

Not so fast. What about those that have been running AP WUs on Linux successfully for some time. I have never seen a "signal 11" and would be very upset to find myself banned from APs because of a catch all rule. Of course I probably just called a "no hitter" and now I will see one :-).

By a coincidental quirk, Sten-Arne's Q8200 system was assigned a task from the last AP WU which has been split: 3933033. The wingmate's host promptly errored its task, so for now there's an unsent reissue task for that WU.

And the only thing that computer is doing, is erroring out every AP it gets. As usual, it's a Linux host getting the infamous "process got signal 11" error (SIGSEGV: segmentation violation).

Why the project continues to send out the app to Linux hosts is beyond me, when 90% of all Linux hosts are incapable of running AP's. As if we had an endless bandwith, the project just keep on sending out 8MB files to be trashed in seconds.

Nobody can make me do anything else than laugh, when they complain about bandwidth saturation, as long as I see this waste of the same bandwith, by sending out thousands of 8MB AP files to Linux hosts, just so they can trash them, and force a resend of the same 8MB file.

Not so fast. What about those that have been running AP WUs on Linux successfully for some time. I have never seen a "signal 11" and would be very upset to find myself banned from APs because of a catch all rule. Of course I probably just called a "no hitter" and now I will see one :-).

It is those Linux machines running stock apps that they are complaining about, you are okay because you run the optimized apps.

---

By a coincidental quirk, Sten-Arne's Q8200 system was assigned a task from the last AP WU which has been split: 3933033. The wingmate's host promptly errored its task, so for now there's an unsent reissue task for that WU.

And the only thing that computer is doing, is erroring out every AP it gets. As usual, it's a Linux host getting the infamous "process got signal 11" error (SIGSEGV: segmentation violation).

Why the project continues to send out the app to Linux hosts is beyond me, when 90% of all Linux hosts are incapable of running AP's. As if we had an endless bandwith, the project just keep on sending out 8MB files to be trashed in seconds.

Nobody can make me do anything else than laugh, when they complain about bandwidth saturation, as long as I see this waste of the same bandwith, by sending out thousands of 8MB AP files to Linux hosts, just so they can trash them, and force a resend of the same 8MB file.

Not so fast. What about those that have been running AP WUs on Linux successfully for some time. I have never seen a "signal 11" and would be very upset to find myself banned from APs because of a catch all rule. Of course I probably just called a "no hitter" and now I will see one :-).

It is those Linux machines running stock apps that they are complaining about, you are okay because you run the optimized apps.

After reading your comment I went back a read Sten's post again and he did mention "app" in the second paragraph. I only picked up on the "Linux hosts" in the third paragraph and thought he was painting with a wide brush. My apologies. I get a little defensive about Linux in a Windows world. Again my apologies.

By a coincidental quirk, Sten-Arne's Q8200 system was assigned a task from the last AP WU which has been split: 3933033. The wingmate's host promptly errored its task, so for now there's an unsent reissue task for that WU.

And the only thing that computer is doing, is erroring out every AP it gets. As usual, it's a Linux host getting the infamous "process got signal 11" error (SIGSEGV: segmentation violation).

Why the project continues to send out the app to Linux hosts is beyond me, when 90% of all Linux hosts are incapable of running AP's. As if we had an endless bandwith, the project just keep on sending out 8MB files to be trashed in seconds.

Nobody can make me do anything else than laugh, when they complain about bandwidth saturation, as long as I see this waste of the same bandwith, by sending out thousands of 8MB AP files to Linux hosts, just so they can trash them, and force a resend of the same 8MB file.

Not so fast. What about those that have been running AP WUs on Linux successfully for some time. I have never seen a "signal 11" and would be very upset to find myself banned from APs because of a catch all rule. Of course I probably just called a "no hitter" and now I will see one :-).

It is those Linux machines running stock apps that they are complaining about, you are okay because you run the optimized apps.

After reading your comment I went back a read Sten's post again and he did mention "app" in the second paragraph. I only picked up on the "Linux hosts" in the third paragraph and thought he was painting with a wide brush. My apologies. I get a little defensive about Linux in a Windows world. Again my apologies.

Sorry dsh but you are in the <1% that do return valid results (Sten was being very generous stating 90%) but a cure is definitely needed for all Linux hosts in this regard.

Cheers.

---

Sorry dsh but you are in the <1% that do return valid results (Sten was being very generous stating 90%) but a cure is definitely needed for all Linux hosts in this regard.

Cheers.

I agree. A cure is definitely needed for all Linux hosts running the stock app if the stock app is the problem.

Sorry dsh but you are in the <1% that do return valid results (Sten was being very generous stating 90%) but a cure is definitely needed for all Linux hosts in this regard.

Cheers.

I agree. A cure is definitely needed for all Linux hosts running the stock app if the stock app is the problem.

It is not that the stock app is the complete problem, it is the fact that it requires a specific update to be installed and most Linux hosts do not have it installed and therefore error out all AP work.

---

^ Is that something that can be fixed by a static link, or is it that it needs a pretty new version of GLIBC? That's the problem I ran into when we went from _v5 -> _v505 on my Linux host at the time. Segment violation was the exact error that I got.

If it needs a newer GLIBC, then why can't it just be re-compiled/coded a slightly different way to be able to use older libraries? The Windows equivalent would be that the stock apps HAVE to have DirectX10 (I know they don't even use it, but it's an example). That would mean that stock would only work on Vista and newer. What about all the millions of XP machines out there?

Is there any specific reason why a newer GLIBC is required?

---

Linux laptop:
record uptime: 1511d 20h 19m (ended due to the power brick giving-up)

It is not that the stock app is the complete problem, it is the fact that it requires a specific update to be installed and most Linux hosts do not have it installed and therefore error out all AP work.

So what is the update ?

I presume its a specific lib file. What's its name and what version is required ?

T.A.

Edit: Yeah, what Cosmic_Ocean said while I was typing :-)

And the only thing that computer is doing, is erroring out every AP it gets. As usual, it's a Linux host getting the infamous "process got signal 11" error (SIGSEGV: segmentation violation).

Why the project continues to send out the app to Linux hosts is beyond me, when 90% of all Linux hosts are incapable of running AP's. As if we had an endless bandwith, the project just keep on sending out 8MB files to be trashed in seconds.

Nobody can make me do anything else than laugh, when they complain about bandwidth saturation, as long as I see this waste of the same bandwith, by sending out thousands of 8MB AP files to Linux hosts, just so they can trash them, and force a resend of the same 8MB file.

That's been fixed by making the stock Cuda apps run twice as long. And if you switch over to the Luna app your completion times double so you get half a cache.

[/s]

Edit: That goes for pre-Fermi Cuda only (I think)

And the only thing that computer is doing, is erroring out every AP it gets. As usual, it's a Linux host getting the infamous "process got signal 11" error (SIGSEGV: segmentation violation).

Why the project continues to send out the app to Linux hosts is beyond me, when 90% of all Linux hosts are incapable of running AP's. As if we had an endless bandwith, the project just keep on sending out 8MB files to be trashed in seconds.

Nobody can make me do anything else than laugh, when they complain about bandwidth saturation, as long as I see this waste of the same bandwith, by sending out thousands of 8MB AP files to Linux hosts, just so they can trash them, and force a resend of the same 8MB file.

That's been fixed by making the stock Cuda apps run twice as long. And if you switch over to the Luna app your completion times double so you get half a cache.

[/s]

I had no idea there was a stock Cuda AP application for Linux hosts. I don't think the project admins do either. You might want to tell them about it sometime. :) Although this is referring to the stock CPU application.

I would think that the AP Linux hosts that can't do the work would be limited in how much work they could get and trash. I had a machine go a big wonky once and started trashing work. Then it was throttled to only being allowed to download 2 tasks at a time to trash. I think they mechanism might have been broken as well in the scheduling updates they did some time ago. Which resulted in the limited being imposed now.

---

SETI@home classic workunits: 93,865 CPU time: 863,447 hours
Join the [url=http://tinyurl.com/8y46zvu]BP6/VP6 User Group[

I had no idea there was a stock Cuda AP application for Linux hosts.

No, it's worse... I'm talking about the Windows stock Cuda app for pre-Fermi cards. And should have said so, of course:)