When you look in your list of tasks, you can check up on the error yourself. Just click on the taskID link and it'll open a page that shows what the output of the task was.
In this case it's "Exit status -1073741795 (0xffffffffc000001d)". This means that (somehow) the task was run by an application that was built with newer instruction sets than your computer is capable of handling. E.g. an application running at SSE2, while your computer can only use SSE, max.
The standard GC applications at Einstein are slightly optimized for CPU instruction sets, yet to then use the correct application, a small program runs before that will check the instruction sets on your CPU and start the correct application on your computer:
* a version that makes use of the SSE2 SIMD instruction set
* a version that makes use of the SSE SIMD instruction , but not SSE2
* a compatibility version for old PCs that do not support SSE or SSE2
ABP2 on the other hand - which is an optional application to run at Einstein - requires that your CPU can use the SSE2 instruction set.
The Cyrix CPU (which your CentaurHauls VIA Samuel 2 CPU is) only uses fpu de tsc msr cx8 mtrr pge mmx 3dnow. It doesn't do SSE2, so you cannot run ABP2 with it. You should therefore disable it in your project preferences - your account -> Einstein project preferences -> Edit them -> Take the check mark off of Arecibo Binary Pulsar Search (STSP) -> Save changes with the button at the bottom of the page.
The next time your BOINC contacts the project it'll immediately use those settings.
E.g. an application running at SSE2, while your computer can only use SSE, max.
I don't really know anything about Cyrix CPUs but I suspect they don't even do SSE.
Quote:
The standard GC applications at Einstein are slightly optimized for CPU instruction sets, yet to then use the correct application, a small program runs before that will check the instruction sets on your CPU and start the correct application on your computer:
* a version that makes use of the SSE2 SIMD instruction set
* a version that makes use of the SSE SIMD instruction , but not SSE2
* a compatibility version for old PCs that do not support SSE or SSE2
That mechanism (small extra program do work out CPU capabilities) hasn't been used for a while now. These days, the server is responsible for choosing and sending the correct version of the GC1 app according to the capabilities reported to it by the client.
Quote:
ABP2 on the other hand - which is an optional application to run at Einstein - requires that your CPU can use the SSE2 instruction set.
ABP2 requires SSE as a minimum. Bikeman recently posted a very nice summary of all the CPU versions of the available applications for both GC1 and ABP2.
I don't have any hosts that aren't at least capable of SSE so I've never seen a problem where ABP2 tasks error out due to instruction set incompatibility. I fully agree with your advice to the OP to disable ABP2 tasks but I'm a bit surprised that the server sent the task in the first place. I had imagined the server would refuse to send work if the host didn't have the ability to process it.
E.g. an application running at SSE2, while your computer can only use SSE, max.
I don't really know anything about Cyrix CPUs but I suspect they don't even do SSE.
No, they don't. (fpu de tsc msr cx8 mtrr pge mmx 3dnow as I posted before)
Quote:
These days, the server is responsible for choosing and sending the correct version of the GC1 app according to the capabilities reported to it by the client.
These used to show in the computer details. I see they're still sent with the sched_request* file, but are we pretty sure they didn't change in name and are still used on the server?
Quote:
ABP2 requires SSE as a minimum. Bikeman recently posted..
Yeah, I used his post as a guide and without thought added a 2. Tsk. :)
Quote:
I fully agree with your advice to the OP to disable ABP2 tasks but I'm a bit surprised that the server sent the task in the first place. I had imagined the server would refuse to send work if the host didn't have the ability to process it.
Perhaps that the client doesn't fully understands what kind of CPU it has. The CPU does do MMX and 3DNow. Any of those confusing the server? (We should find someone with a comparable CPU and have him lift the line out of his client_state or sched_request*.xml file. ;-))
Btw, on my travels I also saw his CPU is 400 MHz. Is that even enough for GC?
Error While Computing
)
When you look in your list of tasks, you can check up on the error yourself. Just click on the taskID link and it'll open a page that shows what the output of the task was.
In this case it's "Exit status -1073741795 (0xffffffffc000001d)". This means that (somehow) the task was run by an application that was built with newer instruction sets than your computer is capable of handling. E.g. an application running at SSE2, while your computer can only use SSE, max.
The standard GC applications at Einstein are slightly optimized for CPU instruction sets, yet to then use the correct application, a small program runs before that will check the instruction sets on your CPU and start the correct application on your computer:
* a version that makes use of the SSE2 SIMD instruction set
* a version that makes use of the SSE SIMD instruction , but not SSE2
* a compatibility version for old PCs that do not support SSE or SSE2
ABP2 on the other hand - which is an optional application to run at Einstein - requires that your CPU can use the SSE2 instruction set.
The Cyrix CPU (which your CentaurHauls VIA Samuel 2 CPU is) only uses fpu de tsc msr cx8 mtrr pge mmx 3dnow. It doesn't do SSE2, so you cannot run ABP2 with it. You should therefore disable it in your project preferences - your account -> Einstein project preferences -> Edit them -> Take the check mark off of Arecibo Binary Pulsar Search (STSP) -> Save changes with the button at the bottom of the page.
The next time your BOINC contacts the project it'll immediately use those settings.
RE: E.g. an application
)
I don't really know anything about Cyrix CPUs but I suspect they don't even do SSE.
That mechanism (small extra program do work out CPU capabilities) hasn't been used for a while now. These days, the server is responsible for choosing and sending the correct version of the GC1 app according to the capabilities reported to it by the client.
ABP2 requires SSE as a minimum. Bikeman recently posted a very nice summary of all the CPU versions of the available applications for both GC1 and ABP2.
I don't have any hosts that aren't at least capable of SSE so I've never seen a problem where ABP2 tasks error out due to instruction set incompatibility. I fully agree with your advice to the OP to disable ABP2 tasks but I'm a bit surprised that the server sent the task in the first place. I had imagined the server would refuse to send work if the host didn't have the ability to process it.
Cheers,
Gary.
RE: RE: E.g. an
)
No, they don't. (fpu de tsc msr cx8 mtrr pge mmx 3dnow as I posted before)
These used to show in the computer details. I see they're still sent with the sched_request* file, but are we pretty sure they didn't change in name and are still used on the server?
Yeah, I used his post as a guide and without thought added a 2. Tsk. :)
Perhaps that the client doesn't fully understands what kind of CPU it has. The CPU does do MMX and 3DNow. Any of those confusing the server? (We should find someone with a comparable CPU and have him lift the line out of his client_state or sched_request*.xml file. ;-))
Btw, on my travels I also saw his CPU is 400 MHz. Is that even enough for GC?