high, is there a optimized client for my opteron- 2.4 ghz amd processor.
does somebody know a site or adress ,or having yourself,i would appreciate an optimizer for it.
There are no officially sanctioned third party optimized science apps for EAH.
In addition, there is really no reason to use an optimized core client, due to the fact it uses so little CPU time as to be virtually invisible in its impact on your overall crunching performance.
One thing to keep in mind is a lot of work was put into getting the most performance out of the current app as possible within the framework of the project protocols. The requirements for accepetance by all the project partners and sponsors of the data output from the hosts is much more stringent than say for SAH, which is why they don't open up the app for the rest of us to play around with.
*Attach to this project the normal way, this will create the required .../boinc/projects/einstein.phys.uwm.edu directory
*Shutdown BOINC
*Cut and paste the app_info text from the previous post into .../boinc/projects/einstein.phys.uwm.edu/app_info.xml
*Download the 2 files at the URLs given above, move them into the .../boinc/projects/einstein.phys.uwm.edu directory
*Start boinc, an Einstein WU should download
Note the above procedure gets you the 32-bit Einstein application which works fine on a 64-bit OS. Remember that if the names or versions of the apps change then you must download the new apps and modify the app_info.xml file to reflect the name of the new apps. So in the future if your system suddenly shows error messages and won't crunch Einstein then check to see if the app name has changed.
Perhaps the server can be set up to issue the 32bit app to 64 bit clients (both Windows and Linux) as has been done at some of the other projects?
Would make life a lot easier and it's less prone to error...
I don't remember if this was the answer from this project or some other, however it was something in line of:
we can do it like this but then we'd assume users have proper ia32 compatibility libraries in place and we don't want to assume this. We'll support 64-bit Linux when we have a native 64-bit application
Which makes a lot of sense if you consider that there are many not-so-tech-savvy users out there. If an user is able enough to create proper app_info.xml and obtain needed files, then this project welcomes her/him. Which is a lot more than some other project which straight rejects any anonymous platform client.
[edit]
There's another issue which is not yet resolved: how to name AMD64 linux platform. autoconfig mostly says it is x86_64-unknown-linux-gnu while there are people that insist it should be x86_64-pc-linux-gnu. I guess this issue will become extinct at the moment when Berkeley provides official AMD64 linux client.
[/edit]
Perhaps the server can be set up to issue the 32bit app to 64 bit clients (both Windows and Linux) as has been done at some of the other projects?
Would make life a lot easier and it's less prone to error...
I don't remember if this was the answer from this project or some other, however it was something in line of:
we can do it like this but then we'd assume users have proper ia32 compatibility libraries in place and we don't want to assume this. We'll support 64-bit Linux when we have a native 64-bit application
Which makes a lot of sense if you consider that there are many not-so-tech-savvy users out there. If an user is able enough to create proper app_info.xml and obtain needed files, then this project welcomes her/him. Which is a lot more than some other project which straight rejects any anonymous platform client.
And it's much, much, much better than a poke in the eye with a sharp stick but that doesn't mean it's good. If the ia32 comapatability libs are not installed then that fact is easy to diagnose and remedy. The argument smacks of plain laziness not common sense.
Quote:
There's another issue which is not yet resolved: how to name AMD64 linux platform. autoconfig mostly says it is x86_64-unknown-linux-gnu while there are people that insist it should be x86_64-pc-linux-gnu. I guess this issue will become extinct at the moment when Berkeley provides official AMD64 linux client.
The projects leading the pack in 64-bit support have shown they ain't waiting until hell freezes over. They've resolved the issue and it works. In spite of what it says in autoconfig, the de facto standard is x86_64-pc-linux-gnu. It works and when it no longer works then it will get fixed. In the meantime it's serving a useful purpose, which is a lot more than can be said for Bekeley's thumb twiddling.
In addition, there is really no reason to use an optimized core client, due to the fact it uses so little CPU time as to be virtually invisible in its impact on your overall crunching performance.
In addition, there is really no reason to use an optimized core client, due to the fact it uses so little CPU time as to be virtually invisible in its impact on your overall crunching performance.
Alinator
I curious, please explain this in more detail.
All the core client (IOW, BOINC itself) does is manage the science apps, schedule the work, run the benchmarks, and handle comm traffic to the project and GUI frontends, none of which is particularly CPU intensive except for the minute or two the benchmarks run every five days. For example, on my home PDC running NT4 Server which got rebooted last week, the CC has run for a total of 10 1/2 minutes out of 168 hours plus of uptime (0.099% utilization).
The vast majority of CPU time is burned by the science apps themselves which is where optimization pays the biggest dividends.
is there a optimized client for a amd-opteron processor??
)
There are no officially sanctioned third party optimized science apps for EAH.
In addition, there is really no reason to use an optimized core client, due to the fact it uses so little CPU time as to be virtually invisible in its impact on your overall crunching performance.
One thing to keep in mind is a lot of work was put into getting the most performance out of the current app as possible within the framework of the project protocols. The requirements for accepetance by all the project partners and sponsors of the data output from the hosts is much more stringent than say for SAH, which is why they don't open up the app for the rest of us to play around with.
Alinator
Follow-on questions: Will
)
Follow-on questions:
Will the existing Einstein science app run on a 64-bit Linux platform (AMD)?
And what's needed to have it downloaded?
Happy crunchin',
Martin
See new freedom: Mageia Linux
Take a look for yourself: Linux Format
The Future is what We all make IT (GPLv3)
RE: Will the existing
)
It will run.
You need the following two files:
http://einstein.phys.uwm.edu/download/einstein_S5R1_4.17_i686-pc-linux-gnu
http://einstein.phys.uwm.edu/download/einstein_S5R1_4.17_i686-pc-linux-gnu.so
And then you need an app_info.xml similar to this one:
[pre]
einstein_S5RI
Faster all-sky pulsar search
einstein_S5RI_4.17_i686-pc-linux-gnu
einstein_S5RI_4.17_i686-pc-linux-gnu.so
einstein_S5RI
417
einstein_S5RI_4.17_i686-pc-linux-gnu
einstein_S5RI_4.17_i686-pc-linux-gnu.so
[/pre]
Metod ...
In the previous post, the
)
In the previous post, the URLs for the files to download are wrong, close but wrong. You want S5RI, not S5R1. Download these instead:
http://einstein.phys.uwm.edu/download/einstein_S5RI_4.17_i686-pc-linux-gnu
http://einstein.phys.uwm.edu/download/einstein_S5RI_4.17_i686-pc-linux-gnu.so
The correct steps to get it all working are:
*Shutdown BOINC
*Cut and paste the app_info text from the previous post into .../boinc/projects/einstein.phys.uwm.edu/app_info.xml
*Download the 2 files at the URLs given above, move them into the .../boinc/projects/einstein.phys.uwm.edu directory
*Start boinc, an Einstein WU should download
Note the above procedure gets you the 32-bit Einstein application which works fine on a 64-bit OS. Remember that if the names or versions of the apps change then you must download the new apps and modify the app_info.xml file to reflect the name of the new apps. So in the future if your system suddenly shows error messages and won't crunch Einstein then check to see if the app name has changed.
BOINC FAQ Service
Official BOINC wiki
Installing BOINC on Linux
Perhaps the server can be set
)
Perhaps the server can be set up to issue the 32bit app to 64 bit clients (both Windows and Linux) as has been done at some of the other projects?
Would make life a lot easier and it's less prone to error...
Join the #1 Aussie Alliance on Einstein
RE: Perhaps the server can
)
I don't remember if this was the answer from this project or some other, however it was something in line of:
we can do it like this but then we'd assume users have proper ia32 compatibility libraries in place and we don't want to assume this. We'll support 64-bit Linux when we have a native 64-bit application
Which makes a lot of sense if you consider that there are many not-so-tech-savvy users out there. If an user is able enough to create proper app_info.xml and obtain needed files, then this project welcomes her/him. Which is a lot more than some other project which straight rejects any anonymous platform client.
[edit]
There's another issue which is not yet resolved: how to name AMD64 linux platform. autoconfig mostly says it is x86_64-unknown-linux-gnu while there are people that insist it should be x86_64-pc-linux-gnu. I guess this issue will become extinct at the moment when Berkeley provides official AMD64 linux client.
[/edit]
Metod ...
RE: RE: Perhaps the
)
And it's much, much, much better than a poke in the eye with a sharp stick but that doesn't mean it's good. If the ia32 comapatability libs are not installed then that fact is easy to diagnose and remedy. The argument smacks of plain laziness not common sense.
The projects leading the pack in 64-bit support have shown they ain't waiting until hell freezes over. They've resolved the issue and it works. In spite of what it says in autoconfig, the de facto standard is x86_64-pc-linux-gnu. It works and when it no longer works then it will get fixed. In the meantime it's serving a useful purpose, which is a lot more than can be said for Bekeley's thumb twiddling.
BOINC FAQ Service
Official BOINC wiki
Installing BOINC on Linux
RE: In addition, there is
)
I curious, please explain this in more detail.
Overclock with the MSI G31M3-L and Intel E8600 3.33Ghz
Intel D865GLC Socket 478 Motherboard Review
Overclock your ASUS 1005HA netbook and crunch more
RE: RE: In addition,
)
All the core client (IOW, BOINC itself) does is manage the science apps, schedule the work, run the benchmarks, and handle comm traffic to the project and GUI frontends, none of which is particularly CPU intensive except for the minute or two the benchmarks run every five days. For example, on my home PDC running NT4 Server which got rebooted last week, the CC has run for a total of 10 1/2 minutes out of 168 hours plus of uptime (0.099% utilization).
The vast majority of CPU time is burned by the science apps themselves which is where optimization pays the biggest dividends.
Alinator
Check into the affinity
)
Check into the affinity option some optimized core clients offer.
Overclock with the MSI G31M3-L and Intel E8600 3.33Ghz
Intel D865GLC Socket 478 Motherboard Review
Overclock your ASUS 1005HA netbook and crunch more