Afaik I did it with ./configure, look at the options, you maybe need to download and compile gtk (+libcul etc.), but after compiling you _don't_ need to do "make install". Just leave the packages somewhere, where you like. When you use ./configure, you can declare the path to these additional needed packages and voila. :)
You dont'n nessesarily need the additional packages after you successfully compiled, because you can do static compilation(default, afair).
the configure file doesnt exist at the beginning, you have to successfully finish the autosetup before you can /.configure.... a bit strange....
Strange, indeed. Last time I compiled, it was included. Did you get the source via cvs, like it's said on the "Compile"-page of seti_brittas's link?
Quote:
but.. hm.. i think at Einstein the benchmark should not matter any more and i think it doesnt make a difference for the einstein client, does it?
No, the benchmark is'n worth anything at E@H anymore, the credits a given from the server independent from client, OS, CPU-speed and benchmark.
Quote:
btw does the "stderr out" change anything? on my notebook, suse linux 10.1 32 bit it says:
5.4.9
2006-06-28 18:37:57.6032 [normal]: Start of BOINC application 'einstein_S5R1_4.01_i686-pc-linux-gnu'.
2006-06-28 18:37:57.8316 [normal]: Started search at lalDebugLevel = 0
2006-06-28 18:37:59.7663 [normal]: Checkpoint-file 'Fstat.out.ckp' not found.
2006-06-28 18:37:59.7667 [normal]: No usable checkpoint found, starting from beginning.
Detected CPU type 1
This is quite normal, when the app is starting a new WU, because then there is no Fstat.out.ckp - file yet.
Quote:
and on my desktop, suse linux 10.1 64 bit it only says:
stderr out
5.4.9
Maybe you use the option of BOINC to redirect it's output?
Quote:
edit: on first test with linux on this desktop i got more credits / hour than on Windows, but i got short WUs here and only long ones on windows.. so i dont know yet if the linux client really is faster or if the short WUs are the reason.. hard to compare
Everybody in our team says, Linux and even *BSD are faster than Windows at the moment. :)
Pretty fair in my eyes, 'cause a lot of people had to suffer with there slow apps, compared to Akos's TURBO-Alberts. ;)
Look at your start script and try "./boinc -h". It will show the option "-redirectio", maybe you find something related. Also ensure the BOINC-user has the necessary rights to write in the /BOINC directory and to the file /BOINC/slots/0/stderr.txt etc. ;)
there is a script "run_manager" that contains
cd "/home/torben/programme/BOINC" && exec ./boincmgr $@
dont really see the sense in running that... And if i start boinc instead of boincmgr that would only be the text based one without progress etc... hm...
And the user is owner of the whole directory.
edit: but i dont have a clue if anyone cares about the stderr out (if its important). if not i could just ignore it....
I posted a message a couple of days ago on the "Optomized[sic] S5SSE3" thread pointing to exactly this discrepancy when the random "scientific method" argument was first raised.
The machine instructions that are being executed to arrive at the "einstein_S5R1_xxxx" executables results differ from one operating system to the next, and they obviously differ from hardware platform to hardware platform. It doesn't matter one bit that some compiler [they are all different too] generates these executables from the "same" source code. The machine instructions that come out after the code generation phase and all kinds of other magic are DIFFERENT. Those machine instructions however are responsible for the result that is being produced by the application.
The speeed differential between the linux and Win32 executables is a clear indication of it and the difference is totally obvious in a hex editor. The operating system by the way has very little influence over an application that spends some 99% of its time in computation loops.
Once you realize that all "einstein_S5R1_xxx" executables are inherently different you have to ask yourself: why can't Akos continue to optimize the Windows executables, and why did the project invest more energy into optimizing the linux executables that contribute much less to the results total.
I don't understand the official E@H position on this ... mostly I suppose because nobody from the project has contributed to the "Optomized ..." thread.
I totally agree with you.
And to add some more, as i'm sure the results generated by intel cpus or amds will differ too( even though both would run on the same OS and using the same application).
There's even a difference between amd cpus. single core cpus produce slightly different results than dual cores.
(That was seen on leiden classical too)
Here my 2c to remember the problem. This WU shows that a Linux-Opteron 175 spent ~25Ks against ~40Ks on my WXp-P4 D940: every 2 WU on my pc Bruce Allen, owner of the other box ;-), crunches 3 WU on his.
Remember that with the S4 apps times were quite similar.
This might be a fluke and then again, maybe, it isn't.
This could be a report of a WU being completed without obvious problems on different HW platforms and then not getting validated.
Quote:
One workunit is completed now, the 3rd result made mine valid.
Lucky me - but then it would mean that there might be some issue with the Mac client :-/
I hope someone from the project can check this specific WU as long as the Deleter has not caught it. The validator might be too picky with this or that distinct result value.
Quote:
Crunch3r wrote:
Quote:
ca_grufti wrote:
Quote:
I posted a message a couple of days ago on the "Optomized[sic] S5SSE3" thread pointing to exactly this discrepancy when the random "scientific method" argument was first raised.
The machine instructions that are being executed to arrive at the "einstein_S5R1_xxxx" executables results differ from one operating system to the next, and they obviously differ from hardware platform to hardware platform. It doesn't matter one bit that some compiler [they are all different too] generates these executables from the "same" source code. The machine instructions that come out after the code generation phase and all kinds of other magic are DIFFERENT. Those machine instructions however are responsible for the result that is being produced by the application.
The speeed differential between the linux and Win32 executables is a clear indication of it and the difference is totally obvious in a hex editor. The operating system by the way has very little influence over an application that spends some 99% of its time in computation loops.
Once you realize that all "einstein_S5R1_xxx" executables are inherently different you have to ask yourself: why can't Akos continue to optimize the Windows executables, and why did the project invest more energy into optimizing the linux executables that contribute much less to the results total.
I don't understand the official E@H position on this ... mostly I suppose because nobody from the project has contributed to the "Optomized ..." thread.
I totally agree with you.
And to add some more, as i'm sure the results generated by intel cpus or amds will differ too( even though both would run on the same OS and using the same application).
There's even a difference between amd cpus. single core cpus produce slightly different results than dual cores.
(That was seen on leiden classical too)
Here my 2c to remember the problem. This WU shows that a Linux-Opteron 175 spent ~25Ks against ~40Ks on my WXp-P4 D940: every 2 WU on my pc Bruce Allen, owner of the other box ;-), crunches 3 WU on his.
Remember that with the S4 apps times were quite similar.
are all the 'critical' messages a result of the 'process got signal 11' message?
Has this anything to do with an 'out of memory' condition? I'm not sure about signal 11...
RE: RE: Afaik I did it
)
Strange, indeed. Last time I compiled, it was included. Did you get the source via cvs, like it's said on the "Compile"-page of seti_brittas's link?
No, the benchmark is'n worth anything at E@H anymore, the credits a given from the server independent from client, OS, CPU-speed and benchmark.
This is quite normal, when the app is starting a new WU, because then there is no Fstat.out.ckp - file yet.
Maybe you use the option of BOINC to redirect it's output?
Everybody in our team says, Linux and even *BSD are faster than Windows at the moment. :)
Pretty fair in my eyes, 'cause a lot of people had to suffer with there slow apps, compared to Akos's TURBO-Alberts. ;)
cu,
Michael
[edit]typo[/edit]
RE: Strange, indeed. Last
)
yes, via cvs. But i'll just use the compiled version since the benchmark isnt important and i only run einstein... so.. thanks anyway :)
hm, i didnt change anything, everything the same as on the laptop.....
edit: second WU with this strange stderr out:
http://einsteinathome.org/task/35513375
RE: RE: Maybe you use
)
Look at your start script and try "./boinc -h". It will show the option "-redirectio", maybe you find something related. Also ensure the BOINC-user has the necessary rights to write in the /BOINC directory and to the file /BOINC/slots/0/stderr.txt etc. ;)
cu,
Michael
hm, i directly start the
)
hm, i directly start the boincmgr
there is a script "run_manager" that contains
cd "/home/torben/programme/BOINC" && exec ./boincmgr $@
dont really see the sense in running that... And if i start boinc instead of boincmgr that would only be the text based one without progress etc... hm...
And the user is owner of the whole directory.
edit: but i dont have a clue if anyone cares about the stderr out (if its important). if not i could just ignore it....
Crunch3r
)
Crunch3r wrote:
Here my 2c to remember the problem.
This WU shows that a Linux-Opteron 175 spent ~25Ks against ~40Ks on my WXp-P4 D940: every 2 WU on my pc Bruce Allen, owner of the other box ;-), crunches 3 WU on his.
Remember that with the S4 apps times were quite similar.
This might be a fluke and
)
This might be a fluke and then again, maybe, it isn't.
This could be a report of a WU being completed without obvious problems on different HW platforms and then not getting validated.
does anyone know what
)
does anyone know what happened here? The PC never made any invalid result before and today two of this:
http://einsteinathome.org/task/36600585
RE: does anyone know what
)
Yes, this two WUs was crunched by app ver. 4.71 not 4.01
RE: RE: does anyone know
)
??
not really
RE: does anyone know what
)
are all the 'critical' messages a result of the 'process got signal 11' message?
Has this anything to do with an 'out of memory' condition? I'm not sure about signal 11...
Udo
