So i have substituted "AuthenticAMD" with "AuthenticAMC" now looking what comes up with the last WU.
May i report the calculated WU or should i delete it due to the "tweaked" app?
Report em, I run that one bit flipped Einstein since 2007-05-21 and have no problems with broken results.
Almost completed at 98.393% and 87260 s runtime.
Should be around 89000 s completed versus approximately 118000 s unpatched (the two previously completed WUs).
Almost completed at 98.393% and 87260 s runtime.
Should be around 89000 s completed versus approximately 118000 s unpatched (the two previously completed WUs).
I have been lurking the forums, and have read the discussion about AMD CPU's and patched .exe's with great interrest.
On my Opteron 265's the runtime went down from about 134000 to 95000 seconds, on workunits of the same type and credit.
Nice work!
Arnulf
Amazing, isn't it! For the fun of it, I downloaded the free version of Visual Studio 2005 (Express Edition?) and played around with it, it seems that the bug in the CPU detection is fixed by now and all it would take to fix this is a recompile. Bernd is aware of the problem.
Amazing, isn't it! For the fun of it, I downloaded the free version of Visual Studio 2005 (Express Edition?) and played around with it, it seems that the bug in the CPU detection is fixed by now and all it would take to fix this is a recompile. Bernd is aware of the problem.
CU
BRM
This is great for my AMD AM2 box which is SSE2 capable, but I've also got an XP 2600 system that only has SSE and this does not resolve that one being slow.
BTW, the XP 2600 system recently got two WUs paired with two Darwin systems which validated, but not mine (Win XP Pro). That's 66 hrs of CPU time crunched for ZERO credit! :-(
(...)
BTW, the XP 2600 system recently got two WUs paired with two Darwin systems which validated, but not mine (Win XP Pro). That's 66 hrs of CPU time crunched for ZERO credit! :-(
(...)
BTW, the XP 2600 system recently got two WUs paired with two Darwin systems which validated, but not mine (Win XP Pro). That's 66 hrs of CPU time crunched for ZERO credit! :-(
And two times you got credits paired with one of these Darwin systems.
I think they should fix this very fast, because this doesn't make any sence at all, it's just a question of luck. This result shows the stupidness: The two hosts crunching with the older apps got the credits and the two doing their work with the newer apps got nothing.
Atm. I have two WUs pending without consensus yet and am thinking about shutting down every host that is going to get another zero credits result.
(...)
I looked at that suspect code in the math lib again and I think that it is not "evil", just not correct. It could be that whoever wrote this, didn't want to exclude all AMDs from SSE2 but only a certain processor family. After the comparison with the string "AuthenticAMD", the code does some more arithmetic with the CPU model and extended CPU model info, (my assembly language knowledge isn't that good anymore), it's possible that the intention was to exclude only the first generation of 130nm "Newcastle" K8s. I think what it actually does might be the opposite: enable SSE2 on the Newcastles and disabling it for all others.
Was there something wrong with the Newcastle SSE2 implementation? I didn't find anything by googling. Maybe it was just plain slow??
(...)
Not as i know, but i go searching.
Clawhammer and Newcastle, that is. Everything that would report Family 15, extended family 0
CU
BRM
Update on the Clawhammer: The first tests hint that box actually gets SLOWER using the patched app (no crashes or stuff, just lame) but we are doing another WU of each just to be extra sure.
Update on the Clawhammer: The first tests hint that box actually gets SLOWER using the patched app (no crashes or stuff, just lame) but we are doing another WU of each just to be extra sure.
Hi Annika!
That would fit my theory that the original intention of the Microsoft programmers was to disable SEE2 arithmetic only on the early K8s because SSE2 was so slow on those machines that standard x86 FPU instructions are faster. However, what actually happens is that ALL AMD K8 processors are slowed down.
(I spent almost a day figuring out what was going wrong there before I noticed that the information at http://www.sandpile.org/ia32/cpuid.htm is plain wrong: in fact all K8 CPUs report the same family and extended family code (15 and 0, resp.)).
Annika, is the slowdown dramatic for the Clawhammer? Or just a bit?
RE: So i have substituted
)
Report em, I run that one bit flipped Einstein since 2007-05-21 and have no problems with broken results.
Muetze
Almost completed at 98.393%
)
Almost completed at 98.393% and 87260 s runtime.
Should be around 89000 s completed versus approximately 118000 s unpatched (the two previously completed WUs).
EDIT: done in 88796 seconds.
Whew that was fast!
RE: Almost completed at
)
Hey, keep on crunching! ;-)
cu,
Michael
Hi! I have been lurking
)
Hi!
I have been lurking the forums, and have read the discussion about AMD CPU's and patched .exe's with great interrest.
On my Opteron 265's the runtime went down from about 134000 to 95000 seconds, on workunits of the same type and credit.
Nice work!
Arnulf
RE: Hi! I have been
)
Amazing, isn't it! For the fun of it, I downloaded the free version of Visual Studio 2005 (Express Edition?) and played around with it, it seems that the bug in the CPU detection is fixed by now and all it would take to fix this is a recompile. Bernd is aware of the problem.
CU
BRM
RE: Amazing, isn't it! For
)
This is great for my AMD AM2 box which is SSE2 capable, but I've also got an XP 2600 system that only has SSE and this does not resolve that one being slow.
BTW, the XP 2600 system recently got two WUs paired with two Darwin systems which validated, but not mine (Win XP Pro). That's 66 hrs of CPU time crunched for ZERO credit! :-(
[edit]total CPU time corrected [/edit]
Seti Classic Final Total: 11446 WU.
RE: (...) BTW, the XP 2600
)
Yes, welcome to the show!
RE: BTW, the XP 2600 system
)
And two times you got credits paired with one of these Darwin systems.
I think they should fix this very fast, because this doesn't make any sence at all, it's just a question of luck. This result shows the stupidness: The two hosts crunching with the older apps got the credits and the two doing their work with the newer apps got nothing.
Atm. I have two WUs pending without consensus yet and am thinking about shutting down every host that is going to get another zero credits result.
cu,
Michael
RE: RE: RE: (...) I
)
Update on the Clawhammer: The first tests hint that box actually gets SLOWER using the patched app (no crashes or stuff, just lame) but we are doing another WU of each just to be extra sure.
RE: Update on the
)
Hi Annika!
That would fit my theory that the original intention of the Microsoft programmers was to disable SEE2 arithmetic only on the early K8s because SSE2 was so slow on those machines that standard x86 FPU instructions are faster. However, what actually happens is that ALL AMD K8 processors are slowed down.
(I spent almost a day figuring out what was going wrong there before I noticed that the information at http://www.sandpile.org/ia32/cpuid.htm is plain wrong: in fact all K8 CPUs report the same family and extended family code (15 and 0, resp.)).
Annika, is the slowdown dramatic for the Clawhammer? Or just a bit?
CU
BRM