Has anyone else noticed that after the outage the linux client has gotten much slower than the windows gui? I have about 6 linux machines and 3 windows machines. Before the recent outage the linux machines were just as fast if not faster than the windows gui, now they're taking 3-4 times as long per unit than they used to. For instance I have an A64 3200+ running redhat 9, and it used to average 2 hours per unit, now it's taking 4-5 for every unit. I just switched one machine from XP to fedora core 2. Before the switch it was averaging two units every 2.5-3 hours. Now it's taking upwards of 7 hours. Meanwhile all of my windows machines are running just fine. Have some changes been made to the linux client?

Looking at the top computers, all are windows boxes ???? today it
only shows 60 machines but when I looked the other day, only one
box was linux out of 100 computers. As a die hard linux fan, I do
find it difficult to believe that there isn't some sore of problem.

I'm seeing the same thing here, I have 2 computers running at work and one at home. During BOINC test my windows box at work was nr 1 (since it's a P4 2.8), second was my Linux box (dual P III 500) and last was my home computer which is only on a few hours a day while both others are on 24/7.

Since the outage my home computer processed more units than my Linux box with less than 1/8 of the uptime. Something in the Linux client is slowing it down, maybe some debug code or did someone buy Micro$oft stocks :))


"reality is an illusion created by a lack of alcohol"

I have the same problem.

I am using new Athlon MP's with linux and the box is a dog. 5 hours per job. My older slower P3's w/windows do a job in 4 hours.

I have re-installed 3 different flavors of linux, tweaked and clocked, I may have to dump these jobs in cache (sorry) and install windows (OMG) on this box if we don't get an answer here!

"Make it idiot-proof, and someone will make a better idiot."

I am running dual athlons 2000+ MP in dual boot and the linux client takes 5:01 hours per job and the windows client takes 3:40 per job.


Those who build the robots will be the first ones the robots kill.

I think this problem is related to this problem: swap memory or swap space = 0
http://setiweb.ssl.berkeley.edu/forum_thread.php?id=322

i use a AMD Athlon(tm) XP 1800+

and this is what i see on mij info page about the computer with Operating System Linux 2.4.21-231-athlon:
Memory 502.67 MB
Cache 256 KB
Swap space 0 MB
Measured floating point speed 814.72 million ops/sec
Measured integer speed 1876.03 million ops/sec

and this is the same processor on the same mobo and memory with Operating System Microsoft Windows 98 SE, (04.10.2222.00):
Memory 510.82 MB
Cache 976.56 KB
Swap space 1300 MB
Measured floating point speed 1790.23 million ops/sec
Measured integer speed 3054.06 million ops/sec

this is why the pc is slower on linux, but i dont now how to change this.


rob

> Looking at the top computers, all are windows boxes ???? today it
> only shows 60 machines but when I looked the other day, only one
> box was linux out of 100 computers. As a die hard linux fan, I do
> find it difficult to believe that there isn't some sore of problem.

Hmmm, I think I may go back to the old program until this is sorted out then.

It's true, the Windows machines are a lot faster. I have a 1700 MHz Intel Mobile which is only half as fast as a windows 2000 machine (Intel Celeron) with 700 MHz. Even though the calculation with windows started some days later it's now higher in the statistics than the linux laptop (in total AND recent).

The good site: with the old seti it wasn't that obvious that the linux clients are that poor programmed. Here it is quite obvious, the linux code is unacceptable slow.

Mermgfurt,

Udo

> The good site: with the old seti it wasn't that obvious that the linux clients
> are that poor programmed. Here it is quite obvious, the linux code is
> unacceptable slow.

Ok, today I tried to compile it myself with full optimizations which has been discussed here:

http://setiweb.ssl.berkeley.edu/forum_thread.php?id=1212

The effect is amazing. The float value has been more than doubled and the integer value has gone up about 60-80% (it seems this depends on the machine/cpu, I tested it on 2 of my machines). The discussion also lead to some strange results: the fastest method is to run the windows client unter linux with wine. But by optimizing the client by hand you came nearly to the windos results. Anyway, I'd say that compiling with the intel compiler might get even faster binaries. But I never used the intel compilers before, IMHO it won't be easy. Strange that the standard GCC 3.x is trying to just optimze the compatibility but not the speed.

So I must apologize: it's not a problem of the seti guys, it's a compiler problem. To get speed you have to bake your own binary with full optimizations.

Mermgfurt,

Udo (I hope someone is still reading this thread also)

> Ok, today I tried to compile it myself with full optimizations which has been
> discussed here:
>
> http://setiweb.ssl.berkeley.edu/forum_thread.php?id=1212
>
> The effect is amazing. The float value has been more than doubled and the
> integer value has gone up about 60-80% (it seems this depends on the
> machine/cpu, I tested it on 2 of my machines).

But how did you get the seti client to compile with optimizations? Everything in the other thread that was successful was only the boinc binary - the seti binary fails with optimizations.

While most of it is way over my head, my understanding is that getting the benchmark up by optimizing the boinc software will only change the amount of credit asked for. The seti binary actually does the work, and if it can't be optimized it won't actually do the work any faster. Correct?

> But how did you get the seti client to compile with optimizations? Everything
> in the other thread that was successful was only the boinc binary - the seti
> binary fails with optimizations.

No, it got compiled with the same optimizations:

CFLAGS & CXXFLAGS had been set to this before doing autoconf & configure:

"-msse2 -funroll-loops -fomit-frame-pointer -ffast-math -mmmx -msse -s -static -fexpensive-optimizations -m3dnow -march=pentium4 -mcpu=pentium4"

The compiling stopped sometimes because of missing include files (assert.h) and a missing minor version (just put it hard into it: minor = 0). After these changes it compiled normally and it runs the whole time. After using it I must say that the sti client itself hasn't got much faster though. Normally I needed 5:30 hrs for one WU I now need approximately 5:00 hrs for it. This looks like the seti client itself is written very poor for the linux community. Here you can optimize whatever you want, the windows boxes will be faster. :(

> While most of it is way over my head, my understanding is that getting the
> benchmark up by optimizing the boinc software will only change the amount of
> credit asked for. The seti binary actually does the work, and if it can't be
> optimized it won't actually do the work any faster. Correct?

Yes, that's the main reason. Anyway, by optimizing the seti client (I used this one: seti_boinc-client-cvs-2004-07-16.zip), it seems that we can get at least a little push. But sure: it's not enough. The linux machines will be slower than the windows ones and that's bad.

Mermgfurt,

Udo

> Yes, that's the main reason. Anyway, by optimizing the seti client (I used
> this one: seti_boinc-client-cvs-2004-07-16.zip), it seems that we can get at
> least a little push. But sure: it's not enough. The linux machines will be
> slower than the windows ones and that's bad.

Ok, going on with my monologue:

In my first attempt I forgot to add -O3 to the compilation parameters. For the boinc client it's no problem, here it was inserted before from the standard compile options. But for the seti client it's a little bit better. The client is getting another 10% faster. But even here it's far away from the windows machines which compute results in almost half of the time.

BTW, since I'm using the new selfcompiled clients (boinc 3.20 & seti 4.00) there has been no new credit for me. Is there someone else who has a similar problem and knows what's going on ? Or is there something I have to do after a version change ?

Mermgfurt,

Udo

> In my first attempt I forgot to add -O3 to the compilation parameters. For the
> boinc client it's no problem, here it was inserted before from the standard
> compile options. But for the seti client it's a little bit better. The client
> is getting another 10% faster. But even here it's far away from the windows
> machines which compute results in almost half of the time.

So far I'm not having any luck in getting any speed increase. The compile parameters you gave earlier did compile, with the exception of the -static parameter. I didn't have the package installed originally, so I added the package for it, but it still gave me an error I haven't gotten sorted out yet. When I dropped the -static, it compiled but actually is SLOWER than the non-optimized compiled version I was using before. My times went from 3:50 to 4:20. I read in another thread that someone else noticed they were running slower using the -ffast-math parameter, so I dropped that and tried again. It just finished a wu that took 4:10 with that change. Of course, some of the difference could just be the normal difference between work units also. Not sure what I'm gonna try now.

> BTW, since I'm using the new selfcompiled clients (boinc 3.20 & seti 4.00)
> there has been no new credit for me. Is there someone else who has a similar
> problem and knows what's going on ? Or is there something I have to do after a
> version change ?

On the number crunching board, one of the developers informed me that there is no public work coded yet for the 4.0 versions, as they're still in alpha. If you have work units already, they would likely run, but Rom said the scheduler won't give any work to 4.0 yet (and also may not be giving any credit either, but that's just a guess on my part). My seti client that I'm working with on this system is 3.10 and it's only getting new work sporadically, while my 3.08 hosts are getting new work consistently. All have boinc 3.20.

I guess for my next attempt I'll try the -O3 and see if maybe that will help me out.

Darren

> I read in another thread that someone else noticed they were running
> slower using the -ffast-math parameter, so I dropped that and tried again. It

I'll test that.

> On the number crunching board, one of the developers informed me that there is
> no public work coded yet for the 4.0 versions, as they're still in alpha. If
> you have work units already, they would likely run, but Rom said the scheduler
> won't give any work to 4.0 yet (and also may not be giving any credit either,
> but that's just a guess on my part). My seti client that I'm working with on
> this system is 3.10 and it's only getting new work sporadically, while my 3.08
> hosts are getting new work consistently. All have boinc 3.20.

Interesting hints. Why do they never say this somewhere on their webpages ? This project seems to change into a big bubble of trash where it's almost impossible to get informations. Another strange thing: you need to extract the cvs versions in order to get the version number. I now tried the version from June, 30, 2004. It's the last 3.08 version, the next
day it's 3.10. *sigh*

What happened to a good project like seti ? Is it changing to a complete windows-project ? No docs, no workung units (after the change to 3.08 I'm not getting anything anymore), no good programmers (slow seti linux version, bad compiled boinc), this looks very much like the typical windows chaos. What will come next ? Do we calculate viruses instead of radio signals ?

Ok, at least the users help each other. Thanx !

Mermgfurt,

Udo

>> Is it changing to a complete windows-project ?
>> What will come next ?
>> Do we calculate viruses instead of radio signals ?


Well, if it were a RedHat project the old seti1 would not be supported and the new project would be "borrowed" from open source but we would have to buy it and pay a subscription to get updates.


"Note to self: Pillage BEFORE you burn."

> Well, if it were a RedHat project the old seti1 would not be supported and the
> new project would be "borrowed" from open source but we would have to buy it
> and pay a subscription to get updates.

Yeah, you might be damn right. BTW: now I'm running boinc 3.20 & seti 3.08 and getting no WUs at all. With seti 4.00 I even got some WUs even though they didn't seem to add to my credits. Now I'm also getting no credits but I can't even calculate WUs...:(

This might be a boinc problem again because there has been no credits calculated from my windows machine and this machine is still running, calculating etc. No credits at all again.

*big sigh*

BTW, it's nice not to be alone with such problems. Let's do something like the "ASA": Anonymous Seti Addicts. We can only discuss our problems but we can't do anything to solve them.

Mermgfurt,

Udo

Don't know if anyone is still following this thread but I think the problem boils down to two things:
1. The way boinc reports floating point, integer speeds and swap space and
what it does with this information wu wise.
2. No version,'source', of boinc/seti is truely optimized for GNU/Linux.
I have identical hp boxes w/1.8 gHz celeron processors and 256 MB ram, one with
Debian, the other with WinXP. Under 'classic s@h' the deb box blew xp out of the
water. This was also the case with the first version of boinc/seti. Now, with the deb box running seti-linux-4.02-686, it lags well behind the xp box.
I also have a laptop with a 2.4gHz celeron processor w/512 MB ram running Deb
w/seti-4.02-686 and the fsck'n xp box is right on its tail.
Some interesting figures:

hp1.8ghz-deb hp1.8ghz-xp acer2.4ghz-deb
-------------------------------------------------------------
MesFlPtSp 488 897 660
MesIntSp 1358 2619 1806
Swap 489 625 486

(I can just see Gates and Ballmer doing the 'monkey-boy' dance)
I call bullshit on these figures and the method by which they were derived.
Don't expect this problem to be looked into any time soon as the boinc/seti
team have their hands full with hardware and software problems.

---

I think your point 1 is the one...

I'm running the same version of boinc on the same machine with two
OS (Debian 3.0 and Windows 2000). So I would expect both clients to be
equally fast. This is quiet true: Both finish their work in about the
same time.

The Problem is: Processor caches are reported differently (and only them)
The Athlon-XP I use has 256K on-chip cache. The linux-client of boinc
reports them, but the win-client finds 976.56K.
Therefore the benchmarks differ greatly: Integer speed about 2400 mops with
linux and over 4000 with windows.
This results in the windows-client requesting nearly the double amount of
credit for the same amount of work on the same machine.

This way I'm really not surprised that both "computers" (as they are two
different ones for boinc) end up with about the same total credit, despite
linux running two thirds of the uptime.

-> The benchmark-algorithm in the windows-client might need fixing...

> This way I'm really not surprised that both "computers" (as they are two
> different ones for boinc) end up with about the same total credit, despite
> linux running two thirds of the uptime.
>
> -> The benchmark-algorithm in the windows-client might need fixing...
>
You might want to try a BOINC CC from this thread : http://setiweb.ssl.berkeley.edu/forum_thread.php?id=11180

The benchmark results of the optimised clients are near to the windows client.
So the client will request nearly the same credits.

---