Shutting down my K8's and Rebuilding with K7's.
13 Jun 2007 15:07:55 UTC
Topic 192844
(moderation:
I have had as many as 35 rigs running exclusively for Einstein. All were Sempron 64's, Athlon 64's, or A64 x2's. The only rigs that would beat the estimated run times for a WU were the Semprons (one at 2.6ghz, the other @2.65ghz)and recently my resurrected K7 (Socket A) mobile Bartons (all 4 over 2.2ghz). There is no reason to pump electricity into processors that are handicapped by the current S5R2 code. I have enjoyed being in the top 25 for over 2 years, but with the current AMD disadvantage, I can no longer justify the expense of maintaining a large inefficient Einstein Farm. I recently ordered a dual core Opteron and now I wonder why. I have read many posts on the topic but have not seen any fix for AMD users. I have a mobile clawhammer x64 pushing Fedora 7 that I may try, but the Sigabart issue still remains. Looks like you can't give away crunch time to Einstein and expect a full pull in return anymore. If I need an attitude adjustment, please feel free to post a sympathy card here, else color me "running dry".
Regards-tweakster
Shutting down my K8's and Rebuilding with K7's.
)
For AMDs under Windows, there is an inofficial solution which involves a trivial 1 byte binary edit of the executable. Not sure what the project officials think about this, tho. An official fix for this problem can be expected with the next release, can't tell you when this will happen, tho.
Under Linux, AMDs should be at no disadvantage compared to Intel CPUs .
EDIT: Under Linux, the sigabrt issue seems to be solved, at least I haven't seen a "signal 11" error in a long, long time.
CU
BRM
RE: I have had as many as
)
It's not official, and certainly not blessed by E@H, but you can find a way here to patch the app to let SSE2 run on K8 systems.
Seti Classic Final Total: 11446 WU.
RE: RE: I have had as
)
Just to avoid misunderstandings (the cited thread is rather long and you don't want to read it all :-) ).
The use of SSE2 does not refer to the hopefully soon to be released optimized app.
Short summary: The compiler used under windows links a math library that has two code paths: one "default" and one using SSE2 instructions for some (not all) of the library's functions.
The library will switch between the two code paths when the program starts, depending on the type of CPU used.
Unfortunatelly, it will not switch to the faster code-path on all AMD K8 CPUs, even tho these CPUs are all SSE2-capable! This would not be so bad in itself (the Linux math lib doesn't use SSE2 at all on most installations), but the default (slower) code path is REALLY slow for one particular function that is rather frequently called by the E@H app.
This is the reason why all CPUs that do not support SSE2 and AMD K8s are quite a lot slower (ca 30 %) under Windows than under Linux.
For the K8s, the rather artificial switch to the slower code path can be removed. For all non-SSE2 CPUs (Intel or AMD), the performance difference will remain until the next release of the science app.
CU
BRM
RE: For the K8s, the
)
I'd like to see some sort of official statement on this by the project team, one way or the other. IMO, a month's span of time since the reporting of this discovery and no commentary on if they're even attempting to circumvent it is quite disheartening. IMO, it appears the staff is content to let R2 "run its' course" in regards to Windows development and hope for smoother sailing with R3...
Between the way this has been handled, SETI's problems, LHC out of work, Orbit not appearing to be making progress other than ways to get donations (which is good, considering our government won't fund it properly), and the fact that I don't care to run climate models or protein folding (stem cell research is more important to me personally), and the rising costs of electricity, I'm starting to get tired of DC... If nothing changes once I hit 500K total for BOINC (should happen within 2 months), I'm probably going to cut back to only doing work during the day instead of 24/7... If things aren't better by year-end, I'll probably be stopping altogether...
IMO, YMMV, etc, etc, etc...
RE: Between the way this
)
Yep. There are plenty that feel the same as you Brian. Yes DC works, we've proved the point, but can we be bothered with it when it doesn't?
I think the year end might be a time for very many people from all projects to have a bit of a rethink....
Waiting for Godot & salvation :-)
Why do doctors have to practice?
You'd think they'd have got it right by now
RE: IMO, a month's span of
)
This is not entirely true. The staff (Bernd, in this case) was actively discussing this problem with me and a fix for this is now already in their source code. The next release will surely have a fix for the AMD problem, but there are other issues as well and it's more reasonable to combine several fixes in a new release, I guess.
CU BRM
RE: RE: IMO, a month's
)
That should not have to come from you. It is a significant enough issue to warrant a "progress report" type of post, similar to what you were suggesting with the "known issues" list. Those of us who care and who do read those kinds of things would appreciate it. It would not be a "waste of time", nor did I mean to imply that I thought your idea about the known issues list was a "waste of time", just that it appears that progress reports are deemed a "waste of time" by several projects. I appreciate the "better spend time on fixing things rather than talking about it", but an official update within a month's time for the 2nd-most active project in the BOINC community is hardly being "too demanding"...
Forgot my tagline:
IMO, YMMV, etc, etc, etc...
Edit #2:
Also, expanding upon this, the way I see it, it would behoove the project team to give some kind of status on the following issues and in the following order:
* Any current known crashes, including some residual SIGABRT
* Windows platform problems (AMD issues, Vista compatibility, etc...)
* "Slow" vs. "fast" host differentiation for better workunit distribution.
Also, I'm not stating that the status need to be "FIXED"...
RE: RE: RE: IMO, a
)
* I would chip in with a query about the status of the optimized apps.
For a long time we were spoiled here with great response and great feedback, I guess we should not get too upset if it drops to "good. I would like to get my other 2 Linux/AMD machines back over here however, but at the moment it seems like a waste of electricity.
RE: * I would chip in with
)
I left that out of my initial list. I felt that stabilization was more important than optimization. Eliminating the AMD penalty isn't really "optimization" as it is "removing an artificial deoptimizer", but I suppose some could argue that it would constitute "optimization" to some degree...
The right level of communication is a difficult thing to achieve. In good times, quarterly is probably sufficient. In bad times, some folks would like daily updates (childishly-unreasonable expectation), some would like weekly (reasonable), and others would be happy with monthly (more-than reasonable).
IMO, YMMV, etc, etc, etc...
Linux/AMD systems are much better off than Windows/AMD. My Win/AMD system is at least 20-30% slower than the same host on Linux. I don't know exactly how much slower it is because of the codepath problem because I haven't modified the application, but the 20-30% figure is what I've seen mentioned...
As an example, the only host I've been able to quickly locate that's somewhat similar to mine is this Athlon 3000+ running on Linux. Even with a slightly longer-running datapack, it completely smokes my system. Looking at the benchmark data, my system is benchmarking at over twice their system and I have 4X the main memory and 2X the L2 cache...
If BRM is reading, if you can show me how to search for an Athlon FX-55 or FX-57 running on Linux, I'd appreciate it. The FX-57 would be closer to the performance of my system, but I would guess the FX-55 would still be considerably faster than mine right now...with an unmodified app.
I want to thank everyone for
)
I want to thank everyone for taking the time to respond. You have all made some excellent points. I have at least 3 AMD San Diego core processors running at 2.7 ghz (mas o meno). When I look at my average RAC for these rigs since mid may it is in the dumper. I cannot afford to shove electricity in these machines when the project I adopted has fielded a POS lead ball called S5R2. I can not continue to invest in perfectly good hardware to support a project that no longer cares about a large segment of its volunteer community(AMD Crunchers). I cannot believe I had to reverse engineer some of my rigs back to K7's. I am also amazed that I should have to hack the projects executable to realize at least parity with the Intel crowd. Frankly, my Dear....this sucks. I guess my lasting impression of Einstein would have to be success breeds contempt. Your reminders about the "bunker mentality" of the admins and the lack of reasonable dialogue with the project manager are on point.
I agree that DC has lost a great deal of interest. They try to run on a shoe string and we get the boot. I will go quietly. My rigs should be dry in about three days. Any other thoughts from the back of the bus (AMD loyalists)?
Regards-tweakster