I see too many client errors.

If you get an error :

Reason: Illegal Instruction (0xc000001d) at address 0x004177BA

it means your processor doesn't support SSE while the official 4.02 requires SSE. You must not return to 4.00, it will not get valid results any longer.

I made ver. 4.02 clients for non-sse processors, so use one of them and you'll get valid results. Download one of those (I don't know which is faster. So try both and use your favorite one) They are optimized w/o SSE.

osecw-402-mmx-r2.zip

osecw-402-mmx-r3.zip

Usage: Make a full backup copy of your boinc folder in case this client damages your data. Stop boinc core client.
Put the contents of this zip file (app_info.xml and an executable) in the project folder. You may overwrite the executable file, and delete fftw.dll.
Restart boinc core client.

But they are not fully test on non-sse processors. If you have problems please post in this thread.

good luck

---

Luckiest in the world. WMD = Weapon of Mass Distraction

Thanks for this.

But it stupid and *very* shortsighted of the official devs not to post a quick note on the main page(or sticky on the board) saying you now (but didnt before)require SSE (even if/when the enhanced client goes into production it may not require SSE).

After all while not cutting edge, I'd hardly call my one non-SSE machine ancient (1.2GHz Athlon[non-XP]) and there are far older, slower machines running BOINC.

don't speak ill of devs ;)

This is a beta site, and they are testing here (and I'm having fun out of it) I saw too many errors to tolerate and posted this.... I hope devs will think about it (yes, I have reported it.) As SETI@home enhanced can take too long time (10 hours) even on my P4 box with my optimized client (and that it's the reference workunit), SSE may be a must. That should be very critical for devs. To tell the truth in the developing stage, 4.01 and 4.02 took too much time to crunch the reference work unit and it's a headache of the developer. So I guess he decided to use fftw w/SSE. But actually there are not so many "long" WUs. Devs will consider the whole situation. They may refuse non-sse processors, or make another decision.

---

Luckiest in the world. WMD = Weapon of Mass Distraction

afterthought: now I think devs may want to see when non-sse users notice it...

---

Luckiest in the world. WMD = Weapon of Mass Distraction

Well, the rest of us that complete a result properly and have other non-SSE hosts crunching the same WU sure notice it! I can't get any of my work validated because of all of the bloody Illegal Instruction errors for work attempted by older host types. I don't think that it's appropriate to distribute applications to hosts that won't be able to process the work properly. Either fix the application or restrict its use to the machines that will be able to produce valid results with it!

---

It may be right. I don't know what devs think....one possibility is they didn't know how many hosts were using non-sse processors. And this is beta test site...if this happened on the public site, it would be a big problem. I hope devs will solve this problem before (when) this probject becomes public. Maybe they are reluctant on this because this is still beta.

---

Luckiest in the world. WMD = Weapon of Mass Distraction

News from the front page:

July 11, 2005
We're having problems reported running the Windows client on older machines (those without SSE capability). I was under the apparently mistaken impression that FFTW checks at run-time to see whether SSE is avaliable. I will be compiling a 2.03 version today that will not include SSE in the FFTW Library. Until I find a way to include both SSE and non-SSE together, we'll need to use the non-SSE version. If you are using Tetsuji Rai's optimized linux build, make sure you only use it on SSE capable machines.

It'll be interesting though. So we move from a 4.00 app to 4.02 to 2.03? Yep, I can follow that. ;)

---

I have no idea what 2.03 means, but it's nice that they will make non-sse version :)

---

Luckiest in the world. WMD = Weapon of Mass Distraction

It'll be interesting though. So we move from a 4.00 app to 4.02 to 2.03? Yep, I can follow that. ;)

Hmmm... I was just assuming it was a typo, but stranger things have happened. ;)

The big question will be: Will it be here before or after the 17 hour to 34 day outage?

---

News from the front page:

July 11, 2005
We're having problems reported running the Windows client on older machines (those without SSE capability). I was under the apparently mistaken impression that FFTW checks at run-time to see whether SSE is avaliable. I will be compiling a 2.03 version today that will not include SSE in the FFTW Library. Until I find a way to include both SSE and non-SSE together, we'll need to use the non-SSE version. If you are using Tetsuji Rai's optimized linux build, make sure you only use it on SSE capable machines.

It'll be interesting though. So we move from a 4.00 app to 4.02 to 2.03? Yep, I can follow that. ;)

This is very strange. Maybe I guess 2.05 is a typo of 2.1.3 or so, which is a version number of fftw library. Devs seem unfamiliar with compiling fftw, so I compiled fftw libraries w/o SSE for Linux and Windows for them, and sent via email. And I sent email I will help them if necessary...weird devs....

And I hope my Linux client, mmx version (no-sse) works fine on non-sse processors...but I cannot test it...

---

Luckiest in the world. WMD = Weapon of Mass Distraction

News from the front page:

July 11, 2005
We're having problems reported running the Windows client on older machines (those without SSE capability). I was under the apparently mistaken impression that FFTW checks at run-time to see whether SSE is avaliable. I will be compiling a 2.03 version today that will not include SSE in the FFTW Library. Until I find a way to include both SSE and non-SSE together, we'll need to use the non-SSE version. If you are using Tetsuji Rai's optimized linux build, make sure you only use it on SSE capable machines.

It'll be interesting though. So we move from a 4.00 app to 4.02 to 2.03? Yep, I can follow that. ;)

This is very strange. Maybe I guess 2.05 is a typo of 2.1.3 or so, which is a version number of fftw library. Devs seem unfamiliar with compiling fftw, so I compiled fftw libraries w/o SSE for Linux and Windows for them, and sent via email. And I sent email I will help them if necessary...weird devs....

2.05?? 4.03? 2.03? I'm getting dizzy.... ;)
Looks like that news post from July 11 just had a typo. It should have been version 4.03, which is what was released for Windows the other day. It would have been much nicer if they used your FFTW non/SSE version, but you can't keep everybody happy!

---

2.05?? 4.03? 2.03? I'm getting dizzy.... ;)
Looks like that news post from July 11 just had a typo. It should have been version 4.03, which is what was released for Windows the other day. It would have been much nicer if they used your FFTW non/SSE version, but you can't keep everybody happy!

You don't have to worry. No substantial changes are found in the source of 4.03. Actually I knew the changes in the source 24 hours ago, but I ignored because it's too trivial and modifications don't affect results/speed, and I didn't notice the change in the version number. As a matter of fact, the version number for Linux doesn't change with the same modified source.

In short, Linux 4.02 = Windows 4.03.

So I guess the version change in Windows client means it's usable with non-sse processors. Just the news statement is insufficient. I wish it were more precise and correct.

If you stick to my optimized client, you don't have to update. Even if I made the newer one, the only change would be the version number :)

hmmmmmm tired. is beta so unstable??

---

Luckiest in the world. WMD = Weapon of Mass Distraction

<b>July 13, 2005</b>
<i>Turns out I blamed FFTW when I should have blamed myself. At some point SSE had been turned on in the Visual Studio project. Version 4.04 should now work on non-SSE machines</i>

No worries! This is what a beta test is for. :)
We now return you to your regularly scheduled crunching...

Tetsuji, I'm still crunching away with your optimized 4.02 and it's still working fine.

---