X using 80% CPU (Lagging SEQ)

[serberus]

I've got TOP running at the moment and its showing X taking 80% +-10% of the CPU, its leaving next to nothing for showeq resulting in very poor performance.

I'm using a fresh install of Redhat 7.2 and have used the desktop wizard so that all the desktop settings are minimal.

650mhz P3
196mb ram

It doesn't seem to do it all the time but I can't see what starts it running slowly.

Thanks for your input.

Serberus

[serberus]

ok, if I open showeq and login to EQ it runs badly, if I open showeq having logged in then it runs fine and continues to run fine after subsequent zone ins.

This may then be a showeq problem and has already been covered in the boards.

sorry for that.

Serberus

[ru486]

I have the same problem here, shortly after decoding, system becomes very sluggish and showeq lags until I kill the showeq process. I am using redhat 7.1 with kernel 2.4.17 , kde 2.2.1.

[nino2469]

having the same issues, anyone know what to do to fix this

[topgun]

Me to
But only after i updated to SeQ v4

[Spaz]

Ditto.

P3 850MHz

Couple hundred meg of RAM.

Running nothing but SEQ it will do this. Amusingly, this allows one to sort of see what really slows the system down while in SEQ.

IE: If I drop to 1 FPS from 10 it will run much better.

When it is running without this bizarre problem, I can kick it up to 30 FPS and turn everything else on with no slowdown at all.

[serberus]

I wasn't aware so many people were suffering from this problem.

I thought it may just be the sluggishness of Redhat 7.2 in general so I put Mandrake 8.1 on and its still running poorly, but only sometimes.

I can't see anything that triggers it and theres no way to make it run faster again that i'm aware of, is this something the ShowEQ developers are aware of?

I don't know if its anything to do with the size of the filters file, i'll read that thread in a sec then come back and apologize for posting about already fixed issues.

Thanks

Serberus

[potionboy]

Have a friend that had this issue. Turned out that the excessive cpu use only occured when the program was maximized. The fix would be to deselect maximize and use the preferences in the showeq.conf file to go full screen.

Perhaps some of you have the same issue.

[fryfrog]

that is a very interesting and retarded at the same time solution to the problem. as soon as my stupid internet connection at home comes back up, i will be certain to test it.

i remember when i FIRST got seq 4 installed, the cpu usage was somewhere around 5-10% but recently its been up around the 30-40% range. i hope the maximize trick helps ;)

[serberus]

Following advice from Spaz I turned my FPS down and that pretty much fixes all the problems. 2FPS is still perfectly acceptable and it runs a hell of a lot better than 10FPS.

Serberus

[notaguru]

I had the same problem and a little research on redhat site found a kb article pertaining to intel chipsets and > 64mb ram. I figured what the hell and took out all but 64mb and its been running fine ever since. This works fine for me since this box only does seq but may not be the perfect solution for someone using it for more.

[fee]

I have been working to identify the cause of this bug for a few weeks now, no such luck yet.

I have noticed that certain window manager seem to make the problem worse than others. I run wmx and tmw, these seem to work pretty well. I have seen other window managers completely freeze up.

fee

[Kuonji]

Same thing is happening to me. I started a thread under 'Mouse is sluggish' near the top of the page. I have used a couple window managers, but Gnome primarily and sometimes it uses 90% of the processor (sluggish) and sometimes it'll be down around 20-40% of the processor.

It seems to be completely random, I've found no common denominator between the amount of mobs in the zone, people in the zone, map complexity, nothing at all...


K6-550 196 pc 100 ram, RH 7.2 Gnome environment, sawfish WM

[Ataal]

I'm not a conspiracy theorist, but maybe Verant has found a way to make SEQ somewhat unusable by sending a buttload of empty packets.......


Hehe, anyway, I've had the same problem with 7.2 RH installed. Although it doesn't happen all the time, probably 75% of the time.

[Cryonic]

http://seq.sourceforge.net/showthread.php?s=&threadid=423

Seems that the window manager (Gnome, Kde, etc...) is the culprit for poor performance.

I'm using icewm (icewm.sourceforge.net) on a P150 laptop and not experiencing any of these issues.

[Zeppo]

This just started happening to me today.
I have had SEQ 4.0 up and running on my system for a few weeks now, but today when I go to a Fear raid, it starts lagging.
I run top and it says SEQ is taking 95% of the CPU.
I haven't changed anything, it just started doing this.
I tried rebooting, rezoning, logging out and back in.
Nothing worked.
I use Gnome and RH7.2
Pentium 233 w/64MRam.
Has worked great until today.

[Cryonic]

Try using a different WM and see if it the behavior continues. A lighter weight WM might free up needed resources for SEQ (e.g. icewm, windowmaker, etc..., not KDE or Gnome/Enlightenment).

[Kuonji]

I'd love to try icewm, is there a walkthrough or guide on compiling it and starting it? or is it pretty straightforward?

[Cryonic]

http://icewm.sourceforge.net

just like SEQ, read the instructions :)

[Kuonji]

well, I installed it, and I ran seq under it. No change...80-90 percent CPU usage randomly from X while seq is open. South Karana, splitpaw, OT, EJ, CoM, zone is largely irrelevant.

I've even tried it using TWM only. (You can't get any more simple than that...anyways, hopefully someone will figure out what is going on soon. ;)

[S_B_R]

Yep, I have now tried Gnome, KDE, and IceWM with a fresh install of linux each time. I basically get the same results... The wierd thing is that SINS does not exhibit this problem. the same zones the same WM... Running ShowEQ, X shoots up to roughly 80 to 90 percent, when I run SINS X never exceeds about 13% and it usually stays much lower like 3 to 5 percent...

Any of the Devs have anything I could try to figure this out? I'm open to anything to help to get this flushed out... ShowEQ is usable under Gnome since the Total CPU usage is around 90%, with X taking about 80+%...

[Yendor]

S_B_R, which Qt are you using? The one Zaphod posted?

I have been unable to recreate this problem on my machine no matter how hard I try.

[S_B_R]

Each time I re-compile a new version form the Trolltech qt-x11-2.3.2.tar.gz soure Tarball.

--- EDIT ---

I went back and looked over Zaphod's text and notice he is issuing alot more options to configure.

./configure -release -shared -gif -xft -sm -system-libmng -system-zlib -system-libpng -system-jpeg -no-g++-exceptions -thread

I have been compiling QT with -thread as the only configure option. So I'm going to give that a shot tonight...

[Ataal]

One of the recommendations was to not run SEQ maximized....I tried it and it worked beautifully. I just expand it to I can't tell the difference between that and maximized and it runs smooooooth.

Anyway, it's kind of a hinky "fix", but at least there IS a fix.

[Kuonji]

I've never ran it 'maximized'....always stretched it, no difference.

[fryfrog]

i'm curious if those ./configure options helped you at all. that is a LOT of switches, and i know i personally only used the -thread option.

i loaded up top while seq had been running for a few days, and noticed X was using about 40% cpu time (on a dual cpu box, which is more like 20%). anyway, i was curios so i went ahead and rebooted the box (i had recompiled showeq, and it had been up for a while... figured i might as well) and then started seq again.

seq was using ~ 4% and X jumping between not being on top and 10% or so. silly showeq, wonder what makes it do that. also, this was with NO everquest running at all. i personally can't TELL its using that much cpu, everything is very responsive and i'm happy with the response and such.

[S_B_R]

Ok, the configure switches did help quite a bit. now X uses roughly 50% of the CPU instead of 80 to 90% as it had been. Even at 50% it still seems pretty high, but its very usable now. I wonder what else I can do...?

[Yendor]

take the FPS down, i go to 50% when i raise FPS too high.

gonna check out those configure switches sometime and see if i can figure out why that made a diff

[Cryonic]

hmm, starting an X app makes X do stuff, seems pretty straight forward. ShowEQ has to make calls into X to get itself drawn, so X has to do some thinking.

[S_B_R]

Originally posted by Cryonic
hmm, starting an X app makes X do stuff, seems pretty straight forward. ShowEQ has to make calls into X to get itself drawn, so X has to do some thinking.

If you read through the thread the way X is responding is abnormal...

[link129]

Hehe, first off SEQ converted me to Gentoo.
Thx for the heads up.

I am seeing the X usage jump to 100 also when seq is started. It is directly correlated to fps. These times are from just starting up seq, not logged into eq, no map up, not maximixed etc.

1fps X= 3.1% CPU .5% SEQ
10fps X= 30% CPU seq not on top
20fps X= 60% CPU .3% SEQ
20+fps X= 100% CPU seq not on top

Like everyone else if I switch to a new desktop, X drops back down to normal.

Running Gentoo linux. With fluxbox v 0.1.9
XFree v 4.2.0 r12 Driver mod= r128

This post is for info, b/c seq is playable @1-5 fps.

[Cryonic]

I've never had SEQ running at anything over 4fps. I haven't seen any reason to have it higher than that. This isn't like Quake where fps and ping are god.

[a_halfling]

I'm running SEQ in FVWM on a slackware 7 install. I have a AMD 233MX and 96 megs of RAM.

This is just my observation, but SEQ appears to use much more CPU when the spawn list is open. I usually run SEQ with everything but the map turned off and it doesn't use too much CPU even with my FPS set at 10. If I open the spawn list my CPU usage will jump to 100% and SEQ will lag.

Now I know next to nothing about how SEQ is programmed but I am wondering if the spawn list is trying to refresh at the same FPS as the map. It may not, but it would explain the excessive CPU usage if the spawn list is trying to refresh at 10 FPS which is what I have my map FPS set to.

[Zaphod]

Originally posted by link129
Hehe, first off SEQ converted me to Gentoo.
Thx for the heads up.

I am seeing the X usage jump to 100 also when seq is started. It is directly correlated to fps. These times are from just starting up seq, not logged into eq, no map up, not maximixed etc.

1fps X= 3.1% CPU .5% SEQ
10fps X= 30% CPU seq not on top
20fps X= 60% CPU .3% SEQ
20+fps X= 100% CPU seq not on top

Like everyone else if I switch to a new desktop, X drops back down to normal.

Running Gentoo linux. With fluxbox v 0.1.9
XFree v 4.2.0 r12 Driver mod= r128

This post is for info, b/c seq is playable @1-5 fps.

A) Despite what you may think this really isn't related to original problem this thread was referencing, that has been fixed.

B) Your problem (and others) is XFree86 4.2.0 for an ATI card (radeon and r128). There was a large performance drop between XFree86 4.1.0 and XFree86 4.2.0. I've currently narrowed their issue down to which Xlib API call is causing it, but haven't worked out exactly why yet.



originally posted by a_halfling
I'm running SEQ in FVWM on a slackware 7 install. I have a AMD 233MX and 96 megs of RAM.

This is just my observation, but SEQ appears to use much more CPU when the spawn list is open. I usually run SEQ with everything but the map turned off and it doesn't use too much CPU even with my FPS set at 10. If I open the spawn list my CPU usage will jump to 100% and SEQ will lag.

Now I know next to nothing about how SEQ is programmed but I am wondering if the spawn list is trying to refresh at the same FPS as the map. It may not, but it would explain the excessive CPU usage if the spawn list is trying to refresh at 10 FPS which is what I have my map FPS set to.

This is not really related to the thread, but you didn't specify which Spawn List you were talking about. The old SpawnList is a fairly old, slow, and a bit of a pig that updates every time anything changes on a spawn (completely unrelated to framerate). On low speed machines you should really use Spawn List 2.

Enjoy,
Zaphod (dohpaZ)

[Alethal]

just to share my experience with this. I had the exact same annoying problem after installing redhat9.
I switched from gnome to kde and it solved this. I guess the best would be to install gentoo and run showeq under fluxbox but I need it too much to spend 4 days compiling stuff hehe.

[Cheshire_Dragon]

Well I guess since this has been pushed up to the top I may as well add along with Alethal. I don't care if I am a little off topic but judging from the last few posts I am reading it looks to be a lag issue. I run SEQ at 10fps and it gets jumpy from time to time and one day I decided taht I didn't want this anymore. I pushed it to 30fps and WOAH! killed the system...I did a little more poking around in the program and found that if you right click on the map screen and go to the 'Map Optimization' selection and check the 'Speed' option. After I did this the mobs, players and myself all ran REALLY smooth. It was as fluid motion as EQ is on my Windows system.

[Irontung]

After much experimentation and changing of window managers and the like, I found the problem (at least on my machine) was directly related to the size of the map.

When I first started SEQ, I resized the map and as I did so, eventually it reached a point where I couldn't resize that part of the SEQ window.

That's the point where 100% CPU usage began. After waiting until I got control of the cursor back, I made the map window just a bit smaller and *voila*, CPU usage dropped to practially nil.

I then tried maximizing the window and CPU usage then jumped to 100% again, returned it to it's normal size and CPU usage dropped again.

Hope this helps.

[Alethal]

Woah... looks like you just squashed the bug mate. It is EXACTLY what you stated. Maybe one of you dev may start looking into this? It should not be too hard to spot the problem in the code now.

[Irontung]

Haha...I didn't really squash it...I just found where the nasty thing was hiding. Not being a coder I can't kill it, we'll need to have one the professional exterminators here take care of that.

[Alethal]

By the way, it does not really solve entirely the problem. The usage will still get a huge drop from time to time even if the map is not maximized. All that you have to do to solve it is update the size of the map by moving the borders.
After that it gets ok for awhile. If you update the map size from time to time... it always works fine.

That sounds like a leak somewhere :p