C37/A36 use on Asus A7v
16 Mar 2006 22:54:21 UTC
Topic 190917
(moderation:
Hi,
3 of my computers working on gravity waves are based on ASUS A7V (AMD socket A) motherboards. They all work fine and have been good citizens with the "official" software. One of them worked fine with either A36 or C37. The other 2 did not produce useful results with either C37 or A36. I have spent some time trying to sort this out with one of the bad behaving computers. Details follow:
THE COMPUTER THAT WORKS: http://einsteinathome.org/host/70956
This computer has a 1.2 ghz cpu oc'd to 1.36 ghz, 512 meg memory, 1012beta bios.
THE COMPUTER THAT DOES NOT WORK: http://einsteinathome.org/host/354235"
This computer has a 1.3 ghz cpu running at 1.3. It is NOT oc'd.
It started with 1011 bios. I reflashed these to the same bios as the functioning A7V. Still did not work. I set bios to "bios defaults". Still did not work. I changed the bios setting for "performance" to normal from optimal. Still did not work.
This computer started with 128 meg of PC100 memory. I replaced that with 256 meg of PC133 memory. Still did not work. I added back the 128 meg and tried it with 384 meg of mixed memory. Still did not work.
This problem has become very frustating and I have run out of ideas. It does not seem to be a problem with the improved code unless it requires 512 meg of memory or something else I cannot determine. Any ideas or similar experiences??
Thanks
Joe B
C37/A36 use on Asus A7v
)
JoeB,
All the changes you've talked about affect your hardware, which is not at issue. None of Akosf's apps stress the hardware any further than any of the official apps (in fact, if tales of lower temps are to believed, Akosf's would seem to be stressing it less). Akosf's optimization is in software tweaks. You've been barking up the wrong tree! :-)
Now, having said that, I wish I could offer you some answer, but alas ... :-{
microcraft
"The arc of history is long, but it bends toward justice" - MLK
You could try version 387.
)
You could try version 387. it’s the first version for old computers. It wasn’t made for such resent computers as yours, but who knows, maybe it works.
Then you're really interested in a subject, there is no way to avoid it. You have to read the Manual.
You are not getting "client
)
You are not getting "client errors", but results that do not agree with the ones from other machines..
So I suspect it could be a rounding difference, rather than a hardware problem.
I have an Athlon 1.3Ghz running with an A7V, but ir runs Linux, so I can't test Akosf's apps on it.
But I'm ocasionally getting some validate errors on it, with Albert's official app. Not as much as one year ago, when lots of Linux results were rejected, until the Einstein's validator was rewritten with wider tolerances. Now it work reasonably well, but I still get some validate errors.
The problem was then discussed in the forums. It seems to be the rounding in double precission floating point arithmetics. Internally, the FPU uses 80 bit values, but in memory is stored in 64 bit format. And different processors, OS, compilers, can generate diferent results according to different rounding.
Perhaps Akosf apps are causing different roundings in your sistem than the official apps. Not suprising, because he uses a new improved main algorithm. The differences could be greater in your system for some reason (chipset, OS, other apps running that force to suspend the calculus often), and enough to get validate errors.
If this is the reason...What to do? Try the 387 version, as already suggested. Or wait for the official app with the improved algorithm, and if it results on validate errors, report it, perhaps the validator needs to be tunned again...
The precision of 387 is
)
The precision of 387 is better than original.
RE: The precision of 387 is
)
And that's very good, but could cause validating problems, too ;-)
With "einstein" original app, one year ago, Linux machines generated the most exact results. The results from two differents Linux machines were always more similar than the results from two Windows machines.
But the validator ofen discarded Linux results, when compared to two Windows ones, (a very common situation because there are a lot more Windows machines participating in the project), despicte the fact Linux result were better.
This was discussed in the forum, specially in the followin thread:
[link]http://einsteinathome.org/goto/comment/7832[/link]
I've read that Linux, by default, lets the FPU to operate in 80 bit mode, while other OS, like FreeBSD, force the FPU to round internally to 64 bit, to achieve more similar results to sistems that always operate with 64 bit precission (SPARC and others)
And the original Einstein app for Windows seemed to work mostly on 64 bit precission, in the default MSVC compiler optimizations.
So, a very accurate result could be a great thing, but has a lot of chances to be rejected by the validator if compared with other machines that have less precision ;-)
RE: RE: The precision of
)
So, what can I do?
RE: RE: RE: The
)
Perhaps a version with forced 64 bit mode (in double precision floating point operations) will be helpful for users experimenting validation problems.
The SSE2 version already does this, always uses 64 bit.
The problem is for processor without SSE2 suport. I don't know much about it, but there is a way to force the 387 compatible FPU's to internally round double precision floats to 64 bits, like FreeBSD does.
I've read it in GCC's web page, I'm trying to find it now..
RE: RE: RE: The
)
Didn't they change the validator to address the problem of results that are "too accurate" I think they fixed the threshold for which results are considered valid.
such things just should not be writ so please destroy this if you wish to live 'tis better in ignorance to dwell than to go screaming into the abyss worse than hell
RE: RE: RE: RE: The
)
I'm sorry Josep, I forget the smile from end of my line...
I think that I can do a SSE (32 bit) based code that can approach the precision of SSE2 (64 bit)... and it will be much faster... I bet you...
RE: I'm sorry Josep, I
)
Ok, we will be happy to test any new version you do...;-)
And for Jordan: yes, they changed the validator, but I still get some occasional validate errors on my Athlon Thunderbird 1.33Ghz with ASUS A7V motherboard on Linux.
And now, that a user is getting invalid results in a similar machine, (perhaps because with Akosf's app he is reaching the same precission or even more than Linux versions) I am just wondering if a new validator adjustement will be necessary, now that Akosf's versions are using another way to compute data. We will see...