LDoN slow

[Tor K'tal]

I am curious if anyone else is having this problem.

After being in a LDoN zone for a couple minutes my SEQ session(s) seems to fall so far behind that I can no longer point at a skittle to get the tool type info, or scroll through the list of spawns or even know where I am in relationship to everything else. When this occures my CPU is maxed out. When I zone out it seems to fix itself. The intial zoning for leaving or succoring in LDoN seems a bit slow for SEQ to process but my belief is it that it is just flushing through some buffer stuff.

System spec stuff:
Celeron 333 (@ 333)
256 MB RAM
Red Hat 8 (kernel version 2.4.20-20.8) (gcc version 3.2)
Linux Kernel version 2.4.20-20.8
SEQ version 4.3.13a (noticed problem 4.3.12 also)

Network config:
DSL Router (pat integrated) -> switch -> hub -> SEQ & EQ machines.

I have dones a few searches and found some LDoN based threads but nothing that seemed to deal with the performance of SEQ in the LDoN zones. Granted my skill at searching are definately lacking, so I might not have search for the right words to find what I was looking for.

I have read through a healthy portion but not all of this thread:
http://seq.sourceforge.net/forums/sh...&threadid=3945
which seems to deal primary with unknown spawns popping up in most every zone and not laggy performance in LDoN zones specificly.


Since LDoN are on a timer and on occation my groups cut them fairly close, I have not checked the console screen to see if a large number of things go scrolling by that might explain it... I will attempt to do so on my next adventure.

~ TK

[S_B_R]

When this occurs open a terminal window and run the top command. 99.999% of the time X will be at the top of the list using the vast majority of available CPU. If that is the case for you try resizing your SEQ window(s). For example if you run SEQ in a Maximized window try un-Maximizing it and just stretching it to fill the screen. If you dont run it Maximized then try running it maximized. usually you'll find a configuration that will clear up the problem.

This issue has plagued SEQ for a very longtime, it is intermittent and random to say the least. If you search the forums for X performance and/or cpu utilization (or some combination there of) leaving out the LDoN part you should find several threads with tips that seemed to work for other people.

--EDIT--
Oh and there's some info in the FAQ as well
http://www.macsrule.com/~seqfaq/seq-...s=&menu=9#4.14

[Tor K'tal]

Thanks for the reply S_B_R

My first thought is that it isn't that same old X eating up CPU cycles issues because it only happens when I am in LDoN zones. But it might well be.

When this occurs open a terminal window and run the top command. 99.999% of the time X will be at the top of the list using the vast majority of available CPU...

I will do that.

...If that is the case for you try resizing your SEQ window(s). For example if you run SEQ in a Maximized window try un-Maximizing it and just stretching it to fill the screen. If you dont run it Maximized then try running it maximized. usually you'll find a configuration that will clear up the problem.

I will even try to attempt this but the lag become so great at times that I can't actually effect anything to do with SEQ (menus, resize, close etc). I can click to another desktop/workspace and everything seems to work great, the CPU utilization goes way down and the system is responsive. But as far as hitting minize or close or unmaximize/scalable buttons it might be a little difficult (will make sure it is scaleable before I enter the zone). We will see though (or atleast I will). The only way I have found to actually kill SEQ when it gets to this state is to go to it's console window and wait for it to come to life and CTRL+C or issues a kill command for the SEQ process itself in a different console window.



I have done some digging on said issues with X eating up huge amount of processor time in the past, though I have never experienced that with this system, my old system had that problem. A few friends of mine have had that problem as well.

My first explination for why my new verse old system works better is that QT wasn't all messed up from me attempting to get it installed/upgraded and pointed to properly.

My thought on why my computer compaired to my friends doesn't see the problem was that the specs for the machine were using significantly different graphics cards. They use AGP graphics cards and I still use a PCI (old Voodoo Banshee).


Is there an easy way to check for what QT version I am running? or atleast that X uses when it is running?
export at a console has this line:
declare -x QTDIR="/usr/lib/qt3-gcc3.2"
but that directory is actually a sym link to qt-3.0.5

As far as I can tell that is the only QT I have installed on my system.



off topic
Are console window and terminal window interchangable? I am wondering if I am using the wrong word to represent what I'm doing. I remember when a terminal was a monitor and keyboard (aka dumb terminal) connected to a mainframe and a console was a Nintendo. Would hate to look like an idiot by calling something simple the wrong thing.

~ TK

Preferably no comments on my/our current ID10T status at this time.
Thank you
The Management

[S_B_R]

I'm not sure what was causes the problem, I know the FAQ says QT but it seems there maybe another culpret.

As far as running the top command open another terminal window before SEQ starts acting wonky, and run top first. Just let it run, and see what happens.

Console and Terminal are generally interchangable. Technically a Console is a root Terminal, or the Terminal where system messages are echo'ed.

[Tor K'tal]

I had another thought that might be relivant. It doesn't matter if I have a map for the dungeon or not for the lag to occure.

Now to wait for raiding to be over for tonight so I can go on an adventure and try some of this stuff.

I'm not sure what was causes the problem, I know the FAQ says QT but it seems there maybe another culpret.

I'm sure if we knew what the cause is/was we/you/they could develope a solid definative solution for it.

~ TK

[S_B_R]

Hmm, some of the first maps that were converted from the SOE format to the SEQ format were excessively large. That did cause some slow downs as I recall.

One other thing, try lowering how fast your map window(s) refreshes. Right click on the map and somewhere in that menu is a setting for "Show FPS" or something like that. I personally run 2 maps both at 4 frames per sencond. Anything over about 1 or 2 fps is probably overkill, but what the hell...

I'm sure if we knew what the cause is/was we/you/they could develope a solid definative solution for it.

The thing is you're the first person to report it in quite sometime. It's entirely possible that this is an all new and unrelated problem.

[Tor K'tal]

things I've checked

Resized window... didn't seem to fix it as much as I would have hoped. It did prolong how it took before it became unusable.

TOP reported that showeq was using all the resources and not X specificly.

the terminal/console window for SEQ keep getting group info updates. Not really anything else, not sure if that means anything. I didn't even notice buff failing messages and stuff, that could have been because cause the group info kept getting pushed to my client so frequently.

~ TK

[S_B_R]

Yep sounds like a totally new issue... not sure what else to do at this point.

[fester]

Originally posted by Tor K'tal
Celeron 333 (@ 333)
256 MB RAM
Red Hat 8 (kernel version 2.4.20-20.8) (gcc version 3.2)
Linux Kernel version 2.4.20-20.8
SEQ version 4.3.13a (noticed problem 4.3.12 also)
~ TK

333 is rather slow. Is anyone else using Seq successfully on a processor that slow?

I used to have a 333 and I had to upgrade. I am not sure if it was before or after I started running two Seq sessions at once.

[futuro]

Originally posted by fester
333 is rather slow. Is anyone else using Seq successfully on a processor that slow?

I used to have a 333 and I had to upgrade. I am not sure if it was before or after I started running two Seq sessions at once.

I'm running it well on a pII 266 laptop.

It's a little slower displaying the map and mobs after 4.3.14 tho. Not bad, it's about 12-20 seconds, depending on the number of mobs, I think

.

[Tor K'tal]

333 is rather slow. Is anyone else using Seq successfully on a processor that slow?

I used to have a 333 and I had to upgrade. I am not sure if it was before or after I started running two Seq sessions at once.

Beleiving that my computer spec could cause some of the slow down I have limited myself to only running 1 SEQ session at a time unless I know I'm going to need more than one (characters in the house in different zones). I would be willing to except this answer if it wasn't for the fact that it only occures in LDoN zones. That isn't entirely true, I get some SEQ slow down when on massive raids (60+ folks around me plus the zone population not including the raid, but I figure that is just cuase player data is very different than NPC data and requires more thinking for SEQ to process, but it still seems extremely functional and usable).

In velious expansion and lower (Kunark, EQ proper) I generally have no problem and my CPU utilization rarely ever gets over 50% any time other than right after zoning. In Luclin and PoP it depends on which zone specificly, some are great some are so so.

I have also found out that the MM themes don't seem to produce the slowness as readily where as the Taki and Mira ones. In Taki it is pretty much guaranteed. There is a good possability I haven't done enough adventures in any of them to make a valid compairson.

It very well could be my machine specs I am just not sure how to test that effectively.

Something I think I will test next time I go into Taki is have the SEQ session point to a different machine going with me, will see if that matters at all. But to be fair I am thinking I should run two sessions and see if one slows down while the other maintains useability. I'm not sure what that would prove or disprove but it might be interesting to see.

~ TK

[fester]

Originally posted by futuro
I'm running it well on a pII 266 laptop.
.

PII 266 is >= 333 celeron. The cache will make a large difference in Linux. I have an old PIII 500 (or is it PII?) that runs circles around a celeron 633 that I often curse. They both have 1 gig ram.

Originally posted by Tor K'tal
Something I think I will test next time I go into Taki is have the SEQ session point to a different machine going with me, will see if that matters at all. But to be fair I am thinking I should run two sessions and see if one slows down while the other maintains usability. I'm not sure what that would prove or disprove but it might be interesting to see.

Well, I can say for sure that when I ran two Seq sessions on a Celeron 333 with 512 megs of ram, it was unusable with severe lag. That was my setup several years ago (pre PoP) and I was forced to upgrade to a P4 1.7ghz. One sessions may have worked, but two would lose sync because Seq couldn't get the packets fast enough from pcap. So if you are trying 2 sessions on a Celeron 333, in my mind you should have trouble. If you didn't before LDON, then it is because you are either more forgiving or Seq got a great deal more efficient than it used to be.

[Tor K'tal]

PII 266 is >= 333 celeron. The cache will make a large difference in Linux. I have an old PIII 500 (or is it PII?) that runs circles around a celeron 633 that I often curse. They both have 1 gig ram.

Celeron has a better on die cache than the P2, which I think had L2 off die, yet, still on the riser card for the SLOT1 interface. The P3 also went with on die L2 cache, has more of the L2 cache than the Celeron and a slightly better layout for the chip thus making it faster, was suppose to have smarter math stuff to where as the celeron still based off the P2 archetecure. Also the socketted P3 run faster than the SLOTted P3s (atleast in my experience) so if you had a SLOT Celeron and a Socketed P3 there could be a very noticable difference in performance. If memory serves correctly the original P3s were slated to use 1/2 speed L2 cache as were the P2's that had the L2 brought on board before they released the P3, where as the celeron's L2 cache ran at the same speed as the proccessor, which is why they out performed comperable speed P2s. I am trying really hard to remember if it was processor speed or front side bus that the cache ran it, either way the point was that P2 originaly ran it at 1/2 of whichever one it was and the celeron used it at full speed.

Well, I can say for sure that when I ran two Seq sessions on a Celeron 333 with 512 megs of ram, it was unusable with severe lag. That was my setup several years ago (pre PoP) and I was forced to upgrade to a P4 1.7ghz. One sessions may have worked, but two would lose sync because Seq couldn't get the packets fast enough from pcap. So if you are trying 2 sessions on a Celeron 333, in my mind you should have trouble. If you didn't before LDON, then it is because you are either more forgiving or Seq got a great deal more efficient than it used to be.

That is an interesting point though, if it isn't getting the data fast enough from pcap that would explain everything. But I'm not sure why it would be expansion specific. Is there a significant amount different data sent to the client based on the expansion you are in? I would think that the communication between client and server (or visa versa) would be uniformed no matter where in the world you were. The same information needs to be sent to the client for the basics no matter where you are. Is it that there is just more to send in other places? I know luclin introduced a significant system requirement upgrade, based primarily around graphics, but how would that effect SEQ? in my mind it shouldn't. Yes I know PoP also introduced another system req upgrade. But nowhere in the system req update/upgrades have they said we will no longer support dial-up connections (meaning they have increased network trafficed to the point a modem running at 42K wouldn't be getting enough or all the data the client needed to function properly).

You mention loosing of sync in SEQ... could you go into more detail about what that means, maybe that is truelly what I'm seeing and just don't know it.

Thanks for all the helpful reply's btw.

~ TK

:edit:
Fixed a quote to appear properly.
Reworded something to try and make it more understandable

[junk]

I'm just curious, what is your frame rate set at in ShowEQ?

[Tor K'tal]

I'm just curious, what is your frame rate set at in ShowEQ?

I beleive they are set at defaults what ever those might be. I don't know that I have ever changed them anyway. On the window itself I see two differen frame rate numbers. At the top of the spawn list it is listed as 10fpm and below the map itself it is listed as 5fps.


Under the option menu:
Fast Machine is NOT selected (which may or may not effect this)
Select on Consider is selected (shouldn't effect this)
Keep Selected Visible is selected (tells the spawn list window to bring the selected spawn into the viewable area 10 times per minute, if I undestand it correctly)
Create Unkown Spawns is selected (I'm not really sure what this does)
Show Spell Messages is selected (this one should self explanitory)

I only run with the main window open and it only contains Spawn List 2 (set on All) and Map. On occation I will put the Spell List up as well, but I haven't been while testing this.

Right clicking on the map area and looking at map optimization it is set to normal (other options are memory and speed).
Checking the Show options from the right click menu, these are what are checked:
Tooltips
Map Lines
Velocity Lines
Player
Player Background
Player View
Grid Lines
Grid Ticks
Locations
Spawns
Spawn Points
Drops
Highlight Considered Spawns
Selections Walk Path
Map Image
(I'm thinking of checking unknown spawns as well)

I updated to 4.3.14 last night and haven't had a chance to check it yet.

Any other information that might be pertinent that you would like me to check on?

~ TK