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 :D

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/showthread.php?s=&threadid=306&highlight=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?

[orenwolf]

Part of my problem was DRI being disabled, which was seriously affecting screen update speed.

However,

Using a CVS build from two days ago, with a make clean, and fresh makefile, configure, and compile, I still see this problem from time to time.

It doesn't appear that screen refreshes are impacted to the point that my position appears to "lag", but what *does* happen is that if I move the mouse to the spawnlist, or a menu, and click on it (or hover over a menu), it can take as long as 5 seconds to respond sometimes, and this is with a Frame rate of "8".

Now, the box is a PIII800 with half a gig of memory and a ATI Rage128 (8mb card) as a system. I was able to run 3.x at 20 fps without incident.

The other thing is, during these instances, the CPU usage skyrockets, compared to when this is not happening.

I haven't been able to see a correlation between zones/combat/people/whatever and this happening, either.

[Yueh]

DRI? Probably a stupid question but what's that?

This is the same issue I have on my original machine. The map seems to update just fine, but the interface is very VERY slow. However, if I maximize then unmaximize the window it works correctly again. Do you see that?

On the second machine, the interface is noticably slower, you can see the dropdowns and hovers draw. Not nearly as slow as this strange high CPU mode you are seeing but slow all the same.

[Pigeon]

Happens to me too...

But when I turn the map off in the 'view' menu, then turn it back on again, the problem goes away, so I don't worry about it.

err btw this is the script I use to update seq...

rm -f /usr/lib/libEQ.a
cp /root/libEQ.seq.a /usr/lib/libEQ.a
cd /root/showeq
gmake uninstall
gmake clean
gmake distclean
export QTDIR=/usr/local/qt-2.3.2
export PATH=$QTDIR/bin:$PATH
export LD_LIBRARY_PATH=$QTDIR/lib:$LD_LIBRARY_PATH
export CXX=g++3
export CC=gcc3
cvs update
gmake -f Makefile.dist
./configure
gmake
gmake install
cd /usr/local/bin
chmod 4555 showeq

the whole thing with libEQ is because I also run sins, and need the sins compatable libEQ when it installs... libEQ.seq.a is the 4e9d one.

[Bonehand]

Ever since version 2.3 or something I have suffered a horrible time with my SEQ boxes. My first was a AMD K2 with a measily 32MB of RAM...seemed to run SEQ fine. After a few upgrades, I started getting serious lag in everything I did while SEQ was running on that box. Originally I thought it was the maps, since some zones lagged worse than others. Even running Mozilla was almost impossible.

I upgraded the machine a few times since then and even on my p3 667, I get the same lag now, but an added amount of hard drive activity. Switching window focus during the drive activity takes upwards of 5 seconds for redraw. For a fast OS, linux is a real bummer sometimes.

Lately, I have been thinking it's not just SEQ, but also problems in QT's...both the home-built and distributed versions since I think it was around 2.3 that the QT requirements were upped to a different version.

:(

[Yueh]

Another data point. Last night I wiped Mandrake and followed Zaphod's instructions to the letter for installing Redhat 7.2/QT/SEQ (compiling my own qt btw). Lo and behold it all works perfectly, SEQ runs like it should, no slowdowns, nothing.

They only difference I could detect in the whole process was that, obviously, the dist was redhat, and he set $CC and $CXX to point at gcc3 for the seq compile. I thought the SEQ configure looked for gcc3 so that shouldn't need to happen. Other than that I have no idea. Just more info :)

[CodE-E]

I also have performance issues with SEQ 4.x while I never had any with SEQ 3.x. I had SEQ 3.x running at a high framerate (I had the "Fast CPU" (or something like that) options on. I tried to tweak SEQ 4.x a bit by turning "Fast CPU" off and limiting the FPS to 5. Doesn't help. :(

It is not the actual framerate which is the problem. The problem are "freezes" - every now and then SEQ 4.x freezes for a bit.

These "freezes" affect all other applications aswell, btw, which really sucks. When SEQ "freezes" for a few seconds, so will, for example, Konqueror.

I used Monkey79's SEQ guide. I am on a PII 300MHz with 192MB RAM system running RedHat 7.2, btw.

[Zaphod]

CodE-E, just an FYI, if you are running with "Fast CPU" off, you should set your framerate to something on the order of 1. This is because with "Fast CPU" off it repaints the map immediately upon getting a ANY spawn movement, player movement, or new spawn. Most people should have "Fast CPU" on, and if you have it off, make sure to set your framerate to 1.

Also, could one of you please do a "Dump Map Info" from the "Debug" menu and post the resulting "mapinfo.txt" file (typically found under /usr/local/share/showeq/"). This gives a lot of detailed information about how you are running your maps and their general performance.

Also, try to figure out what is happening in the zone or what you did just before it "freezes".

Thanks and Enjoy,
Zaphod (dohpaZ)