I'm hearing of this get-together for the first time... when and where would that be? I'd be really interested in meeting some fellow crunchers and staff members RL.
There was a public event in December 2006 http://gwdaw11.aei.mpg.de/eah.php . Too bad, I wasn't there, but would very much enjoy to attend a "scientists meet community" meeting if it's repeated someday, hopefully. Posdam isn't too far away from where I live, anyway (see profile).
Thanks, sounds really interesting.
News from the Opteron: It has crunched 2 WUs now (dual core, of course...) and the speedup seems to be at 45%, which is almost 1,5 times as much as on my Venice... as I said, Opterons (or in any case the Denmark core) seem to be using SSE2 a bit more (it's also a bit more efficient per MHz of clock speed, so it would kinda fit). Not bad, isn't it? :-D
We're still working at getting the Clawhammer to finish some helpful results. Luckily that was a rather elite laptop in it's days ;-) so, a 3200+ is still a very nice CPU meaning we won't have to wait ages. But since you can never let a notebook crunch 24/7 if you want to take it with you and actually use it, we'll have to wait until tonight or tomorrow until we'll be able to say sth...
Thanks, sounds really interesting.
News from the Opteron: It has crunched 2 WUs now (dual core, of course...) and the speedup seems to be at 45%, which is almost 1,5 times as much as on my Venice... as I said, Opterons (or in any case the Denmark core) seem to be using SSE2 a bit more (it's also a bit more efficient per MHz of clock speed, so it would kinda fit). Not bad, isn't it? :-D
(...)
I won't get it.
Either they check in the lib versus the brand ID obtained via CPUID to use functions or the double-sized cache the Opteron owns compared to your Venice-type Athlon64 contributes something in these matters.
In other Aspects the CPUs should be identical.
I own a E6-Sempron64 2800+ (should be "Albany"), anyone wants to crosscheck on this one?
There only 256 kB L2 are available.
Thanks, sounds really interesting.
News from the Opteron: It has crunched 2 WUs now (dual core, of course...) and the speedup seems to be at 45%, which is almost 1,5 times as much as on my Venice... as I said, Opterons (or in any case the Denmark core) seem to be using SSE2 a bit more (it's also a bit more efficient per MHz of clock speed, so it would kinda fit). Not bad, isn't it? :-D
(...)
I won't get it.
Either they check in the lib versus the brand ID obtained via CPUID to use functions or the double-sized cache the Opteron owns compared to your Venice-type Athlon64 contributes something in these matters.
In other Aspects the CPUs should be identical.
I own a E6-Sempron64 2800+ (should be "Albany"), anyone wants to crosscheck on this one?
There only 256 kB L2 are available.
Hi all!
or maybe the actual speedup depends on the type of workunit (frequency). The critical function which is either very slow or SSE2 optimized doesn't seem to be in the innermost hot loop, so it's possible that some workunits ( I would guess those with more sky-positions, see the last number in the debug output in the result) are hit harder by the bug than the other ones.
Would that agree with the test data?
EDIT: Now I see... it's actually slower now?? Could be that this is one of the Athlons that really IS slow on SSE2. Could it be a "Dublin"? That would be based on the early 130nm core, I guess.
(...)
EDIT: Now I see... it's actually slower now?? Could be that this is one of the Athlons that really IS slow on SSE2. Could it be a "Dublin"? That would be based on the early 130nm core, I guess.
(...)
What is slower now?
A "Dublin" actually is a K7 Duron/Sempron, now SSE2 involved here.
I am 200% sure i have a Sempron as CPU rightmark states: AMD Sempron(TM) 64 2800+ Palermo (eh?) DH-E6 20FC2.
I also had a Turion ML-28 DH-E5 which in fact under full load drew more energy out of the wall-plug than the Sempron.
I do not have any patches or so on applied, i only asked if anyone is interested in a check on my cpu with patches.
Because i currently crunch the last two units on this box before i pull it off.
(...)
EDIT: Now I see... it's actually slower now?? Could be that this is one of the Athlons that really IS slow on SSE2. Could it be a "Dublin"? That would be based on the early 130nm core, I guess.
(...)
What is slower now?
A "Dublin" actually is a K7 Duron/Sempron, now SSE2 involved here.
I am 200% sure i have a Sempron as CPU rightmark states: AMD Sempron(TM) 64 2800+ Palermo (eh?) DH-E6 20FC2.
I also had a Turion ML-28 DH-E5 which in fact under full load drew more energy out of the wall-plug than the Sempron.
I do not have any patches or so on applied, i only asked if anyone is interested in a check on my cpu with patches.
Because i currently crunch the last two units on this box before i pull it off.
Ahhhh... OK.
I was a bit confused by the results page for this computer, as it shows that for identical size workunits, it actually took longer for the last 2 resported results (why?? running in Cool'n'Quite mode??).
The "Dublin" Sempron does support SSE2, it's a castrated Athlon 64 (disabled 64 bit instructions and cache cut in half http://www.heise.de/ct/04/17/020/ ).
Oh.
I relied on this information.
Maybe it is wrong or AMD used "Dublin" as a code for more than one CPU either to confuse customer or being confused themselves.
The solution for the different runtimes of WUs on my client(s) is not so plain on hand either: I exchanged the motherboards (including CPUs of course) of this one and this one, which in fact is nailed to 1.6 GHz.
I was not bothering about completing WUs before changing motherboards, so this could be done flawless i think.
But i "rm -rf *" by accident in /var/lib/boinc falsely assuming i were in /var/log/tomcat-5.5 hence the "client detached" under linux. ;)
Oh.
I relied on this information.
Maybe it is wrong or AMD used "Dublin" as a code for more than one CPU either to confuse customer or being confused themselves.
The solution for the different runtimes of WUs on my client(s) is not so plain on hand either: I exchanged the motherboards (including CPUs of course) of this one and this one, which in fact is nailed to 1.6 GHz.
I was not bothering about completing WUs before changing motherboards, so this could be done flawless i think.
But "rm -rf *" by accident in /var/lib/boinc falsely assuming i were in /var/log/tomcat-5.5 hence the "client detached" under linux. ;)
Thanks for the explanation, I really was a bit confused :-)
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?
RE: I'm hearing of this
)
There was a public event in December 2006 http://gwdaw11.aei.mpg.de/eah.php . Too bad, I wasn't there, but would very much enjoy to attend a "scientists meet community" meeting if it's repeated someday, hopefully. Posdam isn't too far away from where I live, anyway (see profile).
CU
BRM
Thanks, sounds really
)
Thanks, sounds really interesting.
News from the Opteron: It has crunched 2 WUs now (dual core, of course...) and the speedup seems to be at 45%, which is almost 1,5 times as much as on my Venice... as I said, Opterons (or in any case the Denmark core) seem to be using SSE2 a bit more (it's also a bit more efficient per MHz of clock speed, so it would kinda fit). Not bad, isn't it? :-D
We're still working at getting the Clawhammer to finish some helpful results. Luckily that was a rather elite laptop in it's days ;-) so, a 3200+ is still a very nice CPU meaning we won't have to wait ages. But since you can never let a notebook crunch 24/7 if you want to take it with you and actually use it, we'll have to wait until tonight or tomorrow until we'll be able to say sth...
RE: Thanks, sounds really
)
I won't get it.
Either they check in the lib versus the brand ID obtained via CPUID to use functions or the double-sized cache the Opteron owns compared to your Venice-type Athlon64 contributes something in these matters.
In other Aspects the CPUs should be identical.
I own a E6-Sempron64 2800+ (should be "Albany"), anyone wants to crosscheck on this one?
There only 256 kB L2 are available.
RE: RE: Thanks, sounds
)
Hi all!
or maybe the actual speedup depends on the type of workunit (frequency). The critical function which is either very slow or SSE2 optimized doesn't seem to be in the innermost hot loop, so it's possible that some workunits ( I would guess those with more sky-positions, see the last number in the debug output in the result) are hit harder by the bug than the other ones.
Would that agree with the test data?
EDIT: Now I see... it's actually slower now?? Could be that this is one of the Athlons that really IS slow on SSE2. Could it be a "Dublin"? That would be based on the early 130nm core, I guess.
CU
BRM
RE: (...) EDIT: Now I
)
What is slower now?
A "Dublin" actually is a K7 Duron/Sempron, now SSE2 involved here.
I am 200% sure i have a Sempron as CPU rightmark states: AMD Sempron(TM) 64 2800+ Palermo (eh?) DH-E6 20FC2.
I also had a Turion ML-28 DH-E5 which in fact under full load drew more energy out of the wall-plug than the Sempron.
I do not have any patches or so on applied, i only asked if anyone is interested in a check on my cpu with patches.
Because i currently crunch the last two units on this box before i pull it off.
RE: RE: (...) EDIT: Now I
)
Ahhhh... OK.
I was a bit confused by the results page for this computer, as it shows that for identical size workunits, it actually took longer for the last 2 resported results (why?? running in Cool'n'Quite mode??).
The "Dublin" Sempron does support SSE2, it's a castrated Athlon 64 (disabled 64 bit instructions and cache cut in half http://www.heise.de/ct/04/17/020/ ).
CU
BRM
Oh. I relied on this
)
Oh.
I relied on this information.
Maybe it is wrong or AMD used "Dublin" as a code for more than one CPU either to confuse customer or being confused themselves.
The solution for the different runtimes of WUs on my client(s) is not so plain on hand either: I exchanged the motherboards (including CPUs of course) of this one and this one, which in fact is nailed to 1.6 GHz.
I was not bothering about completing WUs before changing motherboards, so this could be done flawless i think.
But i "rm -rf *" by accident in /var/lib/boinc falsely assuming i were in /var/log/tomcat-5.5 hence the "client detached" under linux. ;)
RE: Oh. I relied on this
)
Thanks for the explanation, I really was a bit confused :-)
CU
BRM
So i have substituted
)
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?
I reported mine and it got
)
I reported mine and it got validated okay...