performance problems

[Circles]

I recently upgraded my seq box to mandrake 9 (flushed it then fresh install). I am noticing a huge performance problem though. I used to get smooth operation with seq and several browser sessions open with seq set to 10fps, now, even with seq running alone and at 3fps, its very very slugish and pauses very often (sometimes locking for minutes on end).

the system is a celeron 500, 256mb ram, 10gb hard drive with a 1gb swap. resource meter shows no swap file useage (ram is 70% cached)

I'm just not sure where to start with linux to tweak the performance (or look for trouble) specially since it was running so well before (mandrake 8.2 was the last version i ran, and had a "full" install)

[monster69]

Which version of QT did you end up with?

i.e. Did you get QT 3.0.5 Free and install over the one that came with Mandrake 9 or did you get QT 2.3.2 and put it in a different directory and build SEQ against that?

BTW the second method is the preferred method based on other reported experiences with QT 3.0.x.

Monster

[trackerman]

Yeah I'd have to wonder that aswell, I did a new install on a 233mmx, 128Mb ram and did a recompile of Qt 3.0.5 from a link someone posted rather than use the 3.0.5 that comes with Mandrake 9.0.

I do think its a little slower than my old install of mandrake 8.1, But this time I have a heap of other servers running..

[fryfrog]

technically, you shouldn't have to re-compile the qt-3.0.5 that comes with mandrake 9 because it is compiled with gcc-3.2. what you SHOULD do is what umm.. <scrolls down> monster69 suggested.

you should download and compile qt-2.3.2 into a seperate dir (leaving qt-3.0.5 rpm installed!). things have just been seen to work faster and better with the older version of qt. and it won't cause any problems since nothing in mdk or rh are looking for qt-2.3.2 at all :)

[Circles]

im using qt 3.0.5 from the link in the maknkdrake 9.0 install instructions, and compiled it with the -thread option as stated (i followed codepig's guide to do the install)

i have broken decode checked in seq, and the latest cvs (last night) seems to help some, but i still notice pauses (normally only a few seconds in length)

I was mostly wondering if there are any settings in eq that could help/hinder performace, other than the FPS control.

[Circles]

even after a rebuild with the new libEQ, I'm still seeing poor performance. its more noticable in larger zones, if i zoom in, it seems to help. is it possible there is another process that it taking time away from SEQ processing the out of range mob movement?

its mostly hitches now, but some zones, its just bad enough to be unuseable. any advice on where to start would be appreciated.

[Spook]

Run 'top' then shift-p and see where your cycle-time is going.

Also, those running minimalist boxes are going to have more and more difficulty with slow repsonses as the project grows, of course. Some performance improvements on the way from me if no beats me to it in about a month ;) Might consider upgrading anyway.

[Circles]

QT ended up being the culprit afterall, i recenty got qt2.3.2 and all is back to how it used to be. Not sure what is amiss in qt3.x but it is/was the problem

[cbreaker]

On my Mandrake 9 box, I couldn't get SEQ to run when compiling with QT2.3.2 compiled with gcc3. It would segfault right before it should have started displaying graphics. The same QT2.3.2 install was used for many compiles of SEQ that worked on my Mandrake 8 box.

I had to use QT3, and followed the directions as per someone's post.

I have not noticed any performance issues, but the machine is a pretty quick box, 1ghz athlon.

[hawgz]

Running RH8.0, latest CVS, newest libEQ.a myself. Runs on a thinkpad 600 (300mhz, 328 meg ram, etc. etc.)

I compiled with RH8.0 straight out of the box (QT 3.0.5) and everything worked fine for a bit.

Then I started experiencing slow performance. I pulled down QT 2.3.2, compiled into a separate dir, set QTDIR= to point to 2.3.2.

I'm Still getting the same slow performance.

Now, I'm using a telnet session to my eq box to run the keysniffer (compiled with lcc from the keysniffer forum) and it's set to send the key via UDP port 10000 every x seconds. Started at 10 seconds, thought maybe that was too quick and the udp flood was slowing the box down. Changed to 30 seconds on the key send and still no difference.

I've killed every running process that I didn't need for the box, made sure I have all the latest RH8.0 updates, including kernel updates, and I'm still getting crappy performance. After zoning a couple of times, seq seems to lock up but if I wait long enough it'll eventually start updating somewhat. Even after it decodes, it's extremely slow.

[Cryonic]

Did you rebuild SEQ with QT 2.3.2 after you built QT?

[hawgz]

Yeah, guess I should've mentioned that.

I made sure I had the latest cvs/libEQ, recompiled against QT-2.3.2.

I have noticed that it is primarily zones with a large number of Player Characters.

Bazaar, forget it ever decoding or catching up while I'm in zone. Nexus, just as bad.

Was heading to the grey and Neth, Seru, Mons, and the grey all decoded and performance was fine.

Headed to PoN and blam. Right back to long decode time and not keeping up with my movements or mob movements except for very brief periods.

I read something about logs causing issues, so I made sure all the logs were zeroed out. It seemed to help for a bit. I'm going to explore the logging a bit more and see how much I can cut it down, see if it makes a difference.

[Dedpoet]

This may be a non-needed suggestion, but did you remember to right-click on the map and turn on Animate Spawns under the Show menu? The default has this off and will cause the behavior you are experiencing.

[hawgz]

Didn't have animate spawns selected.

I'll give that a try, and if it works ok, I might go back to QT-3.0.5 and see what happens.

Thanks.

[Dedpoet]

That will most likely fix your problem. I -really- don't recommend 3.0.5, yes it works, but it's buggy. You will most likely have worse performance, font issues, choppy movement, etc. I have done extensive testing with multiple versions of QT on Gentoo and keep coming back to 2.3.2.

[Circles]

just wanted to make sure my problem was clear: the problem i had was not slowness, it was flat out locking up, and in some cases processing packets more than 3 minutes after they arrived. I would also see compile problems that would go away on a later attempt.

switching to 2.3.2 got rid of all these problems:
i have not seen any new compile errors on the 3 seq boxes i maintain (all previously had some)
I have not seen SEQ lockup on zoneing, or in high traffice zones.
I no longer get high delays (screen locking for 20 seconds or more)

the three boxes i run are:
333 celeron with 256mb, 4gb hd, 512mbswap
500 celeron, 256mp, 10gb hd, 1gb swap
233 p2, 144mb, 4gb/2gb, 1gb swap

all work perfectly, and because of direct key insertion, the 233 is even working better than ever before (used to take over a minute to decode)

[hawgz]

Ok, been away for awhile and haven't had time to mess with this much but my performance problem seems to be like what is described by Circles.

Zone-in, decode happens pretty quick (using stealh dll keysniffer) but it's like packets aren't being processed for several minutes after zone-in. I can watch the map and see spawns popping up for as long as 3-4 minutes after zoning. And then, SEQ never seems to quite catch up. I ran top and noticed that when showeq is running, X goes from about 1% of cpu cycles to over 10% of cpu cycles, usually around 11.5.

I recompiled qt-2.3.2 and made sure that $QTDIR pointed to the right libs and recompiled showeq again. It seems somewhat better, but still takes quite a while to catch up. Even after it catches up, it is very sporadic. I can watch it as I run across a zone and it's almost like video lag in game. When it's updating, my character point jumps across in spurts. I've tried selecting optimizing map for speed and memory and it has little or no effect.

I made SEQ window smaller and it appeared to help some.

I'm going to take time today to go back to RH7.2 and see what happens. RH8 seems to be slower than previous releases. I may even take a 1.4ghz box I have sitting around and put 7.2 on it and see if it works better.

[hawgz]

Well, I decided NOT to go back to RH7.2 and stay with 8.0. I solved some of the latency issues by searching on TCP/IP performance tuning and changing some of the IP stack settings. I searched on linux tcp/ip performance tuning and came up with these suggestions from:

http://www.psc.edu/networking/perf_tune.html#Linux


echo 1 > /proc/sys/net/ipv4/tcp_timestamps
echo 1 > /proc/sys/net/ipv4/tcp_window_scaling
echo 1 > /proc/sys/net/ipv4/tcp_sack
echo 8388608 > /proc/sys/net/core/wmem_max
echo 8388608 > /proc/sys/net/core/rmem_max
echo "4096 87380 4194304" > /proc/sys/net/ipv4/tcp_rmem
echo "4096 65536 4194304" > /proc/sys/net/ipv4/tcp_wmem

The first 3 echo statments enable some advanced IP stack paramaters. I believe you can get by without timestamps enabled (most systems won't use it for anything). The important parameters are window scaling and sack.

The next statements set the maximum recieve and send window and set memory reserved for TCP send and recieve buffers.

I still have some latency and will be experimenting with the settings listed above until I find the optimum solution for my system. I'm running straight 10mb/half duplex here at the house and have a 3com pcmcia NIC in an IBM Thinkpad 600. I'll post the parameters that I set once I'm done playing with it but for now I am using the settings as listed on the link above and things are much better.