Performance Issues?

[orenwolf]

Greetings All..

I've got a PIII-850 w/512 MB RAM and a Rage128 Video Card, running RH 7.2 at 1024x768.

Should be more than enough horsepower for ShowEQ.

With v3, I could run the map at 15-20 fps no problem (I usually ran it at about 10 since anything above that was a waste anyway IMHO).

Upon installing v4, and using the provided QT RPM's, I've noticed a huge drop in performance. In fact, in some zones, if I set my FPS *above* 3 or 4, seq will suddenly eat all cpu cycles and I'll find that it preempts everything else (to the point that clicking to lower the fps by one can take 25-30 seconds!)

Now, the only real stock changes I've made from the default config was to disable the second map (nowhere to put it realy at 1024x768) and change the map optomization from "normal" to "speed", as well as enabling map NPC names.

So. it begs the question - is SEQ 4 really that much more of a resource hog that I can only hope for 4fps, or is there an issue with something else?

I'm more than prepared to run any benchmarks or configuration changes to try and correct the issue.

[crazdefool]

I am running 15 fps in P3 450 no problem with 256mb ram..something else is probably effecting your performance.

[LordCrush]

We have 2 instances runing on a PII 350 Box at 10fps - no problem, but we use TWM as windowmanager. We access the the linux-seq-server with VNC/X-Windows from WinXp Notebooks

Regards

- Lord Crush

[fryfrog]

i run 3 instances on a dual celeron 366@550 w/ 256mb of ram, running in KDE. all three sessions typically use very little cpu time, and are frequently NOT at the top of the list of top (gtop), unlike v3 which ate about 120% cpu for 3 processes of it.

[BlueAdept]

I have 3 instances of Seti running which takes 99% of my processor power. SEQ 4 seems to run better than SEQ 3 did with this load.

[fryfrog]

actually, i used to run 2 processes of seti at once (one on each cpu) and found that it was actually negativly impacting my performance in X. not sure why, but i don't run em any more

btw, running more than one instance of seti / cpu doesnt' really help much.

[|nero|]

You said you're using QT RPMs...

I'm not sure, but maybe using those RPMs instead of compiling QT 2.3.2 manually with the "./configure -thread" option is hurting your performance?

- |nero| -

[Yueh]

I have the same problem as did quite a few people in this thread:

http://seq.sourceforge.net/showthrea...ht=performance

If SEQ is started up then EQ kicked off it runs miserably slow. If EQ is run, then SEQ started all is well from then on. Even if EQ is shut down and restarted SEQ runs fine. Not sure where to go from there but it is definitely not an isolated problem.

[Ratt]

Can you post the EXACT steps you take to build you SEQ and then the EXACT steps you take to reproduce this problem?

[Yueh]

I haven't updated to the latest CVS. Let me do that tonight and I'll post the results tomorrow assuming it is still a problem.

[orenwolf]

Can you post the EXACT steps you take to build you SEQ and then the EXACT steps you take to reproduce this problem?

As soon as I compile the most recent CVS, I'll let you know.

But generally, the steps are as follows:

1 - Install RH 7.2 (w/default qt package)
2 - Install qt-gcc3 RPM's
3 - Added the following to /etc/profile.d/qt.sh:

export QTDIR=/opt/qt-gcc3-2.3.2
export PATH=$QTDIR/bin:$PATH
export MANPATH=$QTDIR/doc/man:$MANPATH
export LD_LIBRARY_PATH=$QTDIR/lib:$LD_LIBRARY_PATH
export CXX=g++3
export CC=gcc3

4 - make -f Makefile.dist
5 - ./configure && make

That's it.

[Yueh]

I played with this a little last night.

1. make clean
2. cvs update
3. make -f Makefile.dist
4. ./configure
5. make
6. make install
7. replace both .conf files with the new .conf.dist files
8. start showeq
9. start eq

Everything worked great, then exit EQ and showeq becomes one notch better than unresponsive ie. clicking the file menu takes 60 sec to pull up the dropdown. Unfortunately I couldn't get back into EQ to see if it stayed that way.

Obviously this isn't a big issue in this context but it may be indicative of something bad happening.

[serberus]

I've had this problem since I started using v4 - so reference i'm using a P3-650 Laptop with 192mb ram running Mandrake 8.1.

I followed the installation procedures from a thread I can't find anymore which worked perfectly to get v4 running. It was a post by fryfrog.

The strangest thing about the slow performance is its intermittent.

Sometimes SEQ will be running perfectly well at 10fps and other times it will slow to a crawl, once its running slowly it won't go back to running nicely.

It always runs fine at 2 fps however.

I can't see anything that causes it.

Serberus

[Yueh]

Anyone managed to gain any insight into this problem?

I installed Mandrake 8.1 on a completely different machine, followed the appropriate instructions from Zaphod's Help thread, and run seq. On that machine, it is also slow.

One machine, PII 333 running Redhat 7.1 works fine if I maximize the window. That seems to snap it out of whatever ails it. The other machine, PIII 550 running Mandrake 8.1 is just generally slow. It is passable at 10fps but obviously slower to respond than the older machine. I'll put Redhat 7.2 on following Zaphod's post exactly and see what that turns up.

Another oddity is that, on the Mandrake machine, SEQ segfaults a LOT more than the Redhat machine, I've been running both in parallel and the Mandrake one segfaults about every 45 min where the other one runs like a champ.

*shrug*

[Yueh]

*bump* Anyone have anything new?