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/showthread.php?s=&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-faq.html?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

[Cryonic]

I run SEQ on a Quad PPro 200 with no issues that I can tell. SEQ isn't multi-threaded, so the other 3 CPUs spend the vast majority of their time completely idle. I also export the display over my network to a Windows machine running Exceed to actually display SEQ. I keep the map refresh rate down around 2fps since I don't need it to update very fast in the large outdoor zones that I hunt in.

Maybe by this weekend I'll get into an adventure with a couple of friends and record the session just to capture the data.

[fester]

Originally posted by Tor K'tal
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).


I have a friend that 2 boxes from a 28.8 modem (getting 26k connects) at home. He lives in a very secluded location (blame his wife.) He rarely has trouble. Ever since they improved the protocol, the data rate has been excellent. Often in near idle zones, it looks like you are going LD, because the server will not be sending you anything for 2-5 seconds.


Originally posted by Tor K'tal
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 ...


http://www.mobiledyne.com/pub/x86perf.html

Celeron 333 A (the CPU I had was slot1) is a 32k L1, 128K L2 100mhz, 100mhz ram system.

PII 266 is a 32K L1, 512K L2 133mhz, 66mhz ram system.

PII 500 is a 32K L1, 512K L2 250mhz, 100mhz ram system.

PPro 200 is a 16K L1, 256K or 512K L2 200mhz, 66mhz ram system.

From my experience, Linux (and all other unixie like systems) performs significantly better if you have a larger cache. Blame it on the size of the quantum between context switches?

I personally believe the PII 266 and PPro 200 should outperform the Celeron 333A (the one with onboard 128K cache.)



Originally posted by Tor K'tal
[B]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.[B]


This is several years ago, but went something like this:
ShowEQ would eventually get to be 20 or 30 seconds in the past. I would go walk somewhere and stop, then about 30 seconds later ShowEQ is catching up to where I stopped. I never examined it very close, but It appeared to get in a state where the pcap thread could not get enough cpu (or context switches) to go to the OS for the waiting packets before the OS started dropping packets. I forget precisely how it would fail, but it would eventually completely fail. I believe this was actually before Luclin, so before the 64bit encryption. It would take sometimes 10-20 minutes to brute the key.


Originally posted by Tor K'tal
[B]At the top of the spawn list it is listed as 10fpm and below the map itself it is listed as 5fps. [B]


I should have mentioned this before, but I ran at 1 (one) frame per second setting.

I don't know how long you have been running in this setup, but I suspect the new encryption (XOR) is so much leaner on the CPU that the Celeron may have been nearly sufficient.

I believe the LDON maps may have more mobs packed tighter? I believe you should have the same trouble in a zone like Hate or Droga/Nurga.

[S_B_R]

I have successfully ran 4 instances of SEQ 4.3.x on a Cyrix P266+ (200Mhz clock) with 384 megs or ram. I don't think it's an issue with the hard where.

As it stands now my Current SEQ machine is a 400MHz Celeron with 384megs and I have no probelms running 2 instances of SEQ, under KDE, along with XMMS, Mozilla, and Gaim. Plus it's my network Firewall and Fileserver.

Only downside is it takes about 27 minutes to compile SEQ other than that it's just fine :)

[Tor K'tal]

It's been a while since I added anything to this thread that might be considered constructive or helpful, but after last night I might have some new information.

I spent some time in SolC and ChardokB and noticed the exact same problem as I did with LDoN zones. What I found odd was even though I had to fight my way to the entrances of SolC and CharB; Chardock, SolA and B never slowed down once or became laggy in any way. At the time my group was the only one in the any of the 5 zones.

I am curious to know if these zones happen to send more information to the client and slightly different information thus causing SEQ to think longer between important bits of information. This seems very odd and down right stupid from a technicaly stand point, but if SOE had thought, we can do X to make SEQ less effective in these new zones with out giving up too much performance why not. But that is the side of me that believes in consperacies as well. Is there a way for me to check/compair the amount of traffic that is really being sent to the clien in SolB and SolC just so I can look some time?

~ TK

[S_B_R]

Well, I have to say since you seem to be the only person experiencing this, I don't think it's anything SOE is doing to the data stream that is causing this.

I know that's not really helpful, just trying to save some time. It might be worthwhile for you to completely wipe your current SEQ install and start 100% from scratch.
:confused:

[Samefudge]

Well, I have and continue to run SEQ on a P1 150 MMX and other than the 3 hour compile times (compile it while at work usually :D ), I do not have the slow-down issues at all in LDoN zones, so far. I run anywhere from 10 FPS to 4 FPS. Spawn list population is slow sometimes, but at this point that's about the only issue.

[Tor K'tal]

Just for kicks I tried a couple more things and I learned something.

It only slows down and bogs out on one of the two sessions I can run.

If I monitor 10.0.0.2 it slows to a craw and maxes out my CPU usage %. While that is going on if I change workspace the CPU is still maxed out but my other session monitoring 10.0.0.3 seems to be keeping up much better. If I kill the session monitoring 10.0.0.2 the one monitoring 10.0.0.3 catches up and keeps up just fine.

So I'm currently trying to find reasons why it is only bogged down when monitoring Machine A vs Machine B. I highly doubt that the IP Address itself if the cause, but I might have to swap the IPs just to satify my curiosity.

I do have some Windows shares on Machine A that my linux box running SEQ connects to... would those connections themselves possably be causing SEQ to have to sift through too many packets? If that really is the case why isn't slowed down in a larger number of zones than the slect ones I have found?

Thanks for listening and making suggestions.

~ TK