[Muon.FG]7F4 2002-10-04 15:13:25 | Today I've released Beta 3 of the Linux-Client new features: - new developed manualsend - thread support an update is recommended due to bugs in manualsend script on some systems Ronny (7F4) |
Stephen Brooks 2002-10-04 15:46:52 | Just in case anyone wants the URL to go with that... http://www.project4009.de/edownload.htm And now, in German: http://www.project4009.de/gdownload.htm Shouldn't the extensions be .tar.bz2 not .tgz.bz2 since gzip was never used? "As every 11-year-old kid knows, if you concentrate enough Van-der-Graff generators and expensive special effects in one place, you create a spiral space-time whirly thing, AND an interesting plotline" [This message was edited by Stephen Brooks on 2002-Oct-04 at 22:57.] |
[Muon.FG]7F4 2002-10-05 00:09:13 | >Shouldn't the extensions be .tar.bz2 not .tgz.bz2 since gzip was never used? You're right, and I'm wondering why the midnight commander couldn't open he archive, while with pure .tgz extension he actually can ... |
pben 2002-10-05 06:56:24 | I wish to thank [Muon.FG]7F4 fpr his efforts in porting the code. I ran it over night and got several results over 2.8% just like the Windows code was giving me. The SuSE bin worked fine on my LibraNet 2.7 (Debian 3.0) install. Basted of SuSE 8.0 to try out Debian last week and a SuSE user helps with my current backgound toy. Thanks again, |
[ARS]odessit 2002-10-05 07:37:11 | I have some problems here [root@localhost muon]# ./linuxmuon ./linuxmuon: error while loading shared libraries: libstdc++-libc6.1-2.so.3: cannot open shared object file: No such file or directory [root@localhost muon]# [root@localhost muon]# ./manualsend ./manualsend: error while loading shared libraries: libstdc++-libc6.1-2.so.3: cannot open shared object file: No such file or directory [root@localhost muon]# beta2 was working fine bofore that. I simply unzipped the beta3 to the same muon directory and replaced all files. My config: Dell Inspiron 8100 laptop Mandrake 9.0 with develop package installed Intel P3-M 866 MHz Duron 1000 MHz XP 1600+ @ 2000+ |
[Muon.FG]7F4 2002-10-05 07:42:05 | Now, I compile the binaries on a suse 7.0 system (7.0 was released in fall 2000, I guess), so they should run on the most currently used systems. BTW: while testing on my machine (Athlon XP) I realized that the linux client is 30% faster then the windows version (due to compiler optimization, I guess) But I've checked this with only one result and it's just windows 98SE ... |
[Muon.FG]7F4 2002-10-05 07:48:05 | @odessit could you use beta 2/beta 1 binaries?, probably they don't have this old libc installed I can create an additional binary archive with libc 6.2, but binaries in linux are still a problem (ok i could link libs statically -> size increase) |
[ARS]odessit 2002-10-05 07:54:58 | I was able to use beta2 (and beta1 for what it worth) without any problems I do have GeForce Go card with nvidia drivers installed, they have been known to have filesystem corruption issues with some hardware, maybe it is the case. I overrote the beta2 so I can not test if it is still working. Thanks! Odessit. Intel P3-M 866 MHz Duron 1000 MHz XP 1600+ @ 2000+ Feature Request: How about hardcoding a benchmark into the Windows and Linux client? For example a hardcoded run of a 2.2% transfer parameters run 3 times and averaged to take in account statistical deviations with seconds returned as a result? |
huraxprax 2002-10-05 08:33:03 | old version: $ ldd linuxmuon libstdc++-libc6.2-2.so.3 => /usr/lib/libstdc++-libc6.2-2.so.3 (0x4001e000) libm.so.6 => /lib/libm.so.6 (0x40067000) libc.so.6 => /lib/libc.so.6 (0x40088000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) current version: $ ldd linuxmuon libpthread.so.0 => /lib/libpthread.so.0 (0x4001e000) libstdc++-libc6.1-2.so.3 => /usr/lib/libstdc++-libc6.1-2.so.3 (0x40032000) libm.so.6 => /lib/libm.so.6 (0x40077000) libc.so.6 => /lib/libc.so.6 (0x40098000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) had no problems on debian testing. 7F4: is it poosible with kdevelop to make a "clean" source distribution for the users to compile, the configure script right now asks for the KDE libraries. Benno |
[Muon.FG]7F4 2002-10-05 10:26:38 | I've created now: - a binary version build on Suse 7.3 (needs dynamic linked libraries) - a static linked version (a bit larger but need no other libraries) - (@huraxprax) the source version now uses an own Makefile -> no configure script (and with 42kb really small ...) so I hope there are no more compiling/binary issues |
[ARS]odessit 2002-10-05 11:31:11 | Works like a charm Just sent my results and started running the client. Intel P3-M 866 MHz Duron 1000 MHz XP 1600+ @ 2000+ |
huraxprax 2002-10-05 15:38:07 | 7f5: fine odessit: a function to run a result from known parameters should not be difficult (read parameters from a file in results.dat format and calculate the result) abd be useful before we can dare to port it to other architectures. |
huraxprax 2002-10-06 00:37:34 | Sorry I should have looked at the code before posting. The benchmark/comparison mode is already implemented and toggled by the define OPTIMISELOOP. bye, Benno |
[ARS]odessit 2002-10-06 16:20:08 | quote: and it is run by ? EDIT - No..... How do I run it / use it? I've tried the readme, but it's not there (the static version) Intel P3-M 866 MHz Duron 1000 MHz XP 1600+ @ 2000+ |
huraxprax 2002-10-07 07:15:56 | odessit: it is not a switch which you can use in the compiled client, but a preprocessor switch so you have to change this in the source code (and remove the line with srand() in it), then you get the same results on a single machine. A (very bad) result gave the following results on an athlon@1450: standard version 430s, with -O3 414s, with gcc 3.2 and -march=athlon 358s For gcc 3.2 i had to remove the thread code since there is some syntax problem which I don't know, but i have just one CPU so threads wouldn't be used anyway. The results were of course identical. Anyway it looks as if there is still some room for optimisations |