stephenbrooks.orgForumMuon1GeneralLinux-Client Beta 3 released
Username: Password:
Search site:
Subscribe to thread via RSS
[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... big grin

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 frown

[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
big grin

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 ... wink
[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: wink
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 roll eyes
[ARS]odessit
2002-10-05 11:31:11
Works like a charm smile
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 smile

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:
Originally posted by huraxprax:
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

eek eek eek eek eek
and it is run by
 
./linuxmuon - OPTIMISELOOP
?

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 smile
: contact : - - -
E-mail: sbstrudel characterstephenbrooks.orgTwitter: stephenjbrooksMastodon: strudel charactersjbstrudel charactermstdn.io

Site has had 17083498 accesses.