slow downs with seq

[helinewb]

I'm using mandrake 9.2 and my problem is in some zones i get severe seq lag for instance when moving mouse over the map it takes several seconds to update the position,clicking on any menu takes a very long time for the item to display.Im using beta 5.0.5.

My entire linux system is slowed down when this is happening,but the troubling thing is it doesnt happen in every zone just some.I dont know if some option is turned on that shouldnt be ive looked and turned off everything i thought might be producing the slow down.

If anyone has any tips I would appreciate the advice.

TIA

Heli

[myeqt00n]

I use --itemdb-disable.

[Tor K'tal]

Originally posted by helinewb:
slow downs with seq
You too ?

I have a similar type problem. I have not been able to accurately reproduce it nor force it to occure. I have noticed that it only happens when I'm monitor EQ Machine A vs EQ Machine B. To the point I appears that my Linux box is locked up. But if I click to close that SEQ session and wait long enough it will seg fault on close, even though I thought I was shutting it down properly. Then I can move between desktops (workspace maybe) without trouble. The other interesting thing is if I am monitoring both machines I can switch to the desktop with EQ Machine B and monitor it with out any lag at all, unless I wasn't able to close the session monitoring EQ Machine A.

I have also noticed that SEQ 5, uses more CPU time than SEQ 4 and may have something to do it with it.
SEQ 5.0.0.6 = 1 SEQ session sits at 60% or more CPU utilization
SEQ 4.3.19 = 1 SEQ session sits at 20% or less.

Infact while completely idle as far as EQ traffic goes (as in just fired up SEQ and not in EQ) SEQ 5 runs at the 50% or more CPU utilization and SEQ 4 runs at 2% to 8% (mostly sitting at 2%).


Did that make any sense at all?


computer specs for refrences
CPU = Celeron 333 (at 333)
RAM = 512 MB
Distro = Redhat 8
Kernel = 2.4.20-28.8 (RedHat uptodate process installed)
Header for Linux version = 2.4.9-9
GCC = 3.2.0 (rpm installed)
QT = 3.2.3 (self compiled)
x11 = XFree86-4.2.1-23 (rpm installed, with a bunch of other X stuff)
GNOME = 2 something I believe (uses far too many RPMs in my opinion and no clear core RPM for it)
PCAP = libpcap-0.6.2-17.8.0.2 (rpm installed)
glibc = 2.3

My EQ machines litterally are different machines not different EQ sessions on the same machine.



Originally posted by myeqt00n:
I use --itemdb-disable
I do that too
exact lines I use are
./showeq --ip-address=###.###.###.### --itemdb-disable

With the same random bogging down. I have noticed the slow downs most readily occure in LDoN zones, but is not limited to them.


If anyone has any suggests on something to look for or how to capture it so that someone else can anylize the results and figure it out, let me know. And thanks in advance as well.


~ TK

:EDIT: corrected my innability to use quotes correctly.

[Zaphod]

Here is a question for the two of you. Do you know if you have any UDP intensive activities occurring on the EQ machine? These may include UPnP, Voice Over IP (VOIP), file-sharing, audio streaming (internet radio), video streaming, etc.

Tor K`tal, your case very much sounds like you have something else that is being captured in addition to the EQ data streams, especially since it effects monitoring of a specific machine. I'm alsu curious as to when you last ran ShowEQ 4.3.19 for your CPU load numbers since it hasn't really worked since 2/10/04? Also, are you copmaring with the same number and similarly sized map windows (larger map windows require more memory and can cause video card related issues)?


It is also known that for whatever reason certain instanced zones (LDoN/GoD) send down a lot more traffic that ShowEQ has to process. You also get a lot of additional traffic during full group fights.

Enjoy,
Zaphod (dohpaZ)

[Tor K'tal]

--- SEQ 4 vs 5 load numbers ---
I ran SEQ 4.3.x, when SEQ5.0.0.2 or 3 was having that issue with seg faulting after mass group buffs and other such. I believe that particular issue was fixed in 5.0.0.4. I will update to 4.3.20 and give the 4.3.x version another couple goes to test it out. The compile/creation date on the file is Dec. 22, '03 The complete idle number were generated at the time I wrote that post intially as I just fired them up one then the other to find out what they did when before they started processing EQ data.

I noticed and thought it strange that SEQ5 started using more cycles but it seemed faster so I didn't pay any more attention to it other than it was different than SEQ 4.3.x. I attributed this change, possibly misguided to the fact that SEQ fires up a seperate process to capture the packets and all SEQ session tie into that process to grab their data, or did I miss understand, or did I not impliment that feature correctly? Another thought could be that QT 3.2.3 is significanly slower than 3.1 or 3.0 that 4.3 ran on when I fist setup RH8.0 on this machine.

I have seen SEQ 4.3.x bog down similarly in LDoN zones. Top reports the that SEQ is using the majority of the CPU vs some of the older lag out issues of X chewing them up. But in SEQ 5, out of the gate X jumps to the 50% mark just apon SEQ starting. I will have to take another look to see if X stays at that point and SEQ bogs down or it is a X issue. If I start a second session of SEQ to monitor another machine X stays around 60%, which I find fairly odd.

--- Window size / possition ---
I have tried full screen views of the SEQ session as well as significantly scaled down, to the point I can't actaully see the map or spawn list, but the console window is still very much behind. Top also doesn't report a change in utilization for X. Infact X doesn't even give up any cycles when SEQ is completely minimized. Close all my SEQ session and it drops back down to near nothering.

note: Out of the gate, implise SEQ has started and done all it inilization and is waiting for an EQ session to pop up to monitor.

--- Other UDP applications ---
I know that various other application do crash my SEQ session. One of those applications is EQIM (the sony distributed one). Because of that, I have tried to be very attentive to what applications I actually have running when I fire up EQ.

On occation I do run an AIM session when I play EQ, but that is actually running off my linux box and my AIM client is closed on my EQ machine.

As per my regestry and startup group I don't have anything starting with out my knowledge on my windows machine that has any network traffic tied to it. As per task man's networking my windows machine isn't doing anything before I execute EQ.


Tell me what to try and I will try it.

One of the things I have noticed is that when it seems to start to bog down, I can see a tell or group or other standard message come across my screen while playing EQ and look at my console window in SEQ and there is a notable pause before that message come up there (has to be a chat channel SEQ recognizes). After a long enough period it will have fallen far enough behind that I can zone a few times and then wait and see the map change, everything process for the map with gunk messages hinting that it couldn't figure out what message type it was in eqstr_us.txt file. then the map will change again and it will do the same thing till I think it has finally caught up.

If I had to make a guess, for some reason the SEQ session isn't grabbing the packets out of the capture buffer fast enough anymore for whatever reason. That in and of itself is very much beyond my coding abilities to dive into the code and figure out. If SEQ does actually get a buffer from the pcap library or the pcap library feeds a buffer in SEQ, that would probably be where I would look first. Second I might look into QT doing something odd, but I tend to not think it is QT related due to the funny way 2 sessions don't change the load on the machine if both sessions are idle.

But I am sure Zaphod can take some of this info and hit me back with a check this or that to help him narrow down where to start the hunt, or maybe it will just click and he will say TK you moron, do this and all will be well. And I'm sure he will be right about both the moron and all is well comment.

~ TK

[Tor K'tal]

So I have been running 4.3.21 since the last time I posted here and found that it runs with a ton less CPU utilization than 5.x.

At first I just tried monitoring 1 session with 4.3 and one with 5.x in thinking it was a problem with one of my EQ machines. But as I noted before 5.x instantly sends my CPUU to 50% or better just because it started, but 4.3 lets it sit in the very low sub 5 or 6 range. I also found that running different SEQ versions didn't elivate the problems I was facing with just my CPU being too bogged down to function. I thought this might be due to me monitoring one session with 4.3 and another with 5.x. So then I started monitoring 2 sessions using the 4.3 version and while not playing EQ it still sat below the 10% range.

In a heavy raid it will get up to the 75-80 mark constantly and peak out at 100. But it never falls behind to where it zones but I have already passed through and moved to a different zone. In a regular groups it sits below 50 the majority of the time but does occation and some what frequently spike to 100.

Another difference is that in Bastilion of Thunder my CPUU isn't insanely high even when the zone is empty from other players (rare I know, but I see it on occation). With 5.x I zone in to BoT and my CPU is constantly at 100 if I monitor machine 1 vs machine 2, but monitoring only machine 2 it is also way up in the 80 range. Using 4.3 it is below the 50% mark the majority of the time again, with the spike to 100 and then down.


Another thing I have attempted to do is turn on session monitoring and then go the extra step of telling SEQ to refresh what it is watching everytime I crash or log in or leave the world. Some days I forget and think WTH is going on but then it dawns on me. It prevents a healthy number of seg fault from bad traffic. And it might even reduce CPUU for all I know.


There is on occation a time when monitoring machine 1 the zone map shows up but nothing else (PCs, NPCs, etc) ever shows up on the map, unless I actually target it and con it or otherwise do something to make SEQ catch it (I'm not sure what that something is, it just seems to happen when I con it) and then it is is seen as an unkown grey dot. In that case I switch to the session watching machine 2 and it's all good. Zone and the session monitoring machine 1 comes back to accurate information.

Any other suggestions?

While I have found a work around for my particular problem, I would much rather be using the 5.x version of SEQ.

~ TK

[Tor K'tal]

I guess I spoke too soon. Last night in BoT the session monitoring machine 1 became so bogged down my linux box almost stopped responding. What I found extremely interesting was that my CPU utilization was below 15% when this happened and I couldn't get a top openned up to actually see what was using the CPU. I attempted to close the SEQ session and after a minute or so of waiting (probably a bit less) there was a seg fault in the console window and my system began functioning again.

~ TK

[Cleric]

How much HD space do you have in these cases? One thing I found was with logging enabled there were occassions I could fill my partition where my log file was located and this would cause SEQ to crash. I now have SEQ on a 1Ghz PIII with 120GB HD and 512MB RAM and I rarely see utilization go over 10%... I now have some basic logging enabled (I used to have it off when I was running 4.3.xx on my older box (a PII 450 with 256MB and 12GB drive).... HD space and speed are big factors for SEQ....

[Tor K'tal]

Originally posted by Cleric
How much HD space do you have in these cases? One thing I found was with logging enabled there were occassions I could fill my partition where my log file was located and this would cause SEQ to crash. I now have SEQ on a 1Ghz PIII with 120GB HD and 512MB RAM and I rarely see utilization go over 10%... I now have some basic logging enabled (I used to have it off when I was running 4.3.xx on my older box (a PII 450 with 256MB and 12GB drive).... HD space and speed are big factors for SEQ....


Good point, but I think I have plenty of space avail. And I don't beleive I have any logging going on, as far as network traffic. I do log spawn locations.


#df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/hda1 7558368 3998804 3175616 56% /

#fdisk
Disk /dev/hda: 255 heads, 63 sectors, 1027 cylinders
Units = sectors of 1 * 512 bytes

Device Boot Start End Blocks Id System
/dev/hda1 * 63 15358139 7679038+ 83 Linux
/dev/hda2 15358140 16482689 562275 82 Linux swap
I don't think it is a file space issue, based on those numbers. But maybe I'm not reading them and understanding them correctly. Not sure if my meminfo will have any relivance, but here it is anyway. It probably fluxuates a lot more when SEQ is doing work, rather than sitting idle as I read the boards and stuff. I will try and catch a time when it is bogged down.

# cat /proc/meminfo
total: used: free: shared: buffers: cached:
Mem: 261599232 257998848 3600384 0 41033728 127959040
Swap: 575758336 288825344 286932992
MemTotal: 255468 kB
MemFree: 3516 kB
MemShared: 0 kB
Buffers: 40072 kB
Cached: 60800 kB
SwapCached: 64160 kB
Active: 192712 kB
ActiveAnon: 125512 kB
ActiveCache: 67200 kB
Inact_dirty: 0 kB
Inact_laundry: 38828 kB
Inact_clean: 4792 kB
Inact_target: 47264 kB
HighTotal: 0 kB
HighFree: 0 kB
LowTotal: 255468 kB
LowFree: 3516 kB
SwapTotal: 562264 kB
SwapFree: 280208 kB

I initially posted that I had 512 MB of RAM in that system. But this obviously says different, after physically opening the case, it really only has 256MB. That means 1 of 2 things, I highjacked a stick of RAM out of it in a pinch or I had forgetten and just posted the wrong number thinking all the systems in the house had a min of 512 in them. My money is on the second option, because of the swap partition size. If I did my math correctly in converting from the sectors to size, it is roughly 256MB in size (a bit more), would mean when I installed linux I put a 2xRAM size swap partition for the 128MBs of RAM in the system originally. Then it got a hand me down as one of the other systems in the house got upgraded to 512.

Suggest away on things for me to try.
Suggest away on things for me to check.

For the first time last night, on a really heavy raid in PoAir, my session monitoring machine 2 bogged out. When that workspace was active the CPUU was at 100% when the workspace with session for machine 1 was up CPUU was below 20%. When I tried to close the session for machine 2 I had to wait a moment and then a gnome window popped up asking if I wanted to wait for the application or to kill it cause it was taking too long. I selected kill.

I have seen that similar window with SEQ5, and the session monitoring machine 1 didn't seg fault out when I clicked to close it properly. Not sure if that matters much, or is even a hint.

~ TK

[don'tdoit]

BTW, this exact thing happens to me occasionally. Any info I can provide to supplement what's been provided, let me know. Using gentoo and the problem occurs with either version 4.x or 5.x.

[Zaphod]

What kind of video card do you have?

Enjoy,
Zaphod (dohpaZ)

[Tor K'tal]

The two cards in my system, that's right no sound card.


#cat /proc/pci

...

Bus 0, device 11, function 0:
VGA compatible controller: 3Dfx Interactive, Inc. Voodoo Banshee (rev 3).
IRQ 11.
Non-prefetchable 32 bit memory at 0xd4000000 [0xd5ffffff].
Prefetchable 32 bit memory at 0xd6000000 [0xd7ffffff].
I/O at 0xe400 [0xe4ff].
Bus 0, device 15, function 0:
Ethernet controller: Digital Equipment Corporation DECchip 21142/43 (rev 65).
IRQ 15.
Master Capable. Latency=32. Min Gnt=20.Max Lat=40.
I/O at 0xe800 [0xe87f].
Non-prefetchable 32 bit memory at 0xd9000000 [0xd90003ff].

Not sure if the question of video card was dirrected at me or not.
In plain english it is a Voodoo Banshee PCI with 16MB onboard RAM. Old I know, but fairly stable with decent linux drivers. I wouldn't play a modern 3D game on it, but it does 2D just great.

Network card is a Kingston KNE100TX. Again old, but worked for a realy long time before and still gets me on the internet.


The more I try and remember when the problem started the more I am thinking it was when the QT version was updated. Which means it could be that I hadn't upgraded QT properly. But I have no idea how to figure out if that is it with out blasting my system, which is something I would like to avoid. The fact that people report running clean installs of RH9 and Mandrake9 and Gentoo and various other distro's that don't require QT to be updated, also make me think that probably isn't it.

~ TK

[fryfrog]

What kernel you using? I just tried 2.6.3 and it actually seemed to conflict with my system, causing slowdowns and hickups. I am about to go back to seq 4.x and kernel 2.4.x and see how it does.

[Tor K'tal]

Originally posted by fryfrog
What kernel you using? I just tried 2.6.3 and it actually seemed to conflict with my system, causing slowdowns and hickups. I am about to go back to seq 4.x and kernel 2.4.x and see how it does.


# cat version
Linux version 2.4.20-28.8 ([email protected]) (gcc version 3.2 20020903 (Red Hat Linux 8.0 3.2-7)) #1 Thu Dec 18 12:53:39 EST 2003

Looks like version 2.4.20-28.8

~ TK

[fryfrog]

Linux 2.4.22-gentoo-r7 #12 SMP Wed Mar 3 19:58:14 EST 2004 i686 Celeron (Mendocino) GenuineIntel GNU/Linux
gcc (GCC) 3.3.3 20040217 (Gentoo Linux 3.3.3, propolice-3.3-7)
g++ (GCC) 3.3.3 20040217 (Gentoo Linux 3.3.3, propolice-3.3-7)
qt-3.3.1


I just switched to 2.4.22 kernel and showeq 4.3.21 and everything seems to be much better. I run with the --disable-itemdb option, and while idle X is using approx 33% and 2x SEQ sessions are using 10% each. The system is still responsive, but this just seems like a lot of cpu usage for what should be basically idle.

[Cryonic]

except that SEQ isn't truly idle. Just because you aren't logged into EQ, doesn't mean that SEQ isn't looking at and trying to decode packets going by the SEQ listening interface.

[don'tdoit]

Bus 0, device 2, function 0:
VGA compatible controller: Intel Corp. 82815 CGC [Chipset Graphics Controller] (rev 2).
IRQ 9.
Prefetchable 32 bit memory at 0xf8000000 [0xfbffffff].
Non-prefetchable 32 bit memory at 0xff080000 [0xff0fffff]. Everything (nic,vid,sound) is onboard the mobo.
Kernel is linux-2.4.20-gentoo-r9.

[Tor K'tal]

I recently changed to KDE over GNOME, it seemed okay tonight after I did that. But I will have to spend more time with it to be sure.

~ TK

[Omiime]

just wondering. when you get this problem, you ever click the terminal window and see whats happening ?

I always get tons of these....something like this , I forgot the real message

arq seq give up ..... lines and lines of it.
Then sometimes seq keeps working , most often it doesn't, have to rezone or relog.

When that happens, it really slows down the machine for while.

I use to run seq on dual pent 3 500's 512megs. Use to take forever, for that arq thing to finish.

On my new machine, pent 4 3.0 800fsb 2 gigs. Goes really fast but I still get the arq thing.

[Tor K'tal]

Originally posted by Omiime
just wondering. when you get this problem, you ever click the terminal window and see whats happening ?

I always get tons of these....something like this , I forgot the real message

arq seq give up ..... lines and lines of it.
Then sometimes seq keeps working , most often it doesn't, have to rezone or relog.

When that happens, it really slows down the machine for while.

I use to run seq on dual pent 3 500's 512megs. Use to take forever, for that arq thing to finish.

On my new machine, pent 4 3.0 800fsb 2 gigs. Goes really fast but I still get the arq thing.


I believe I posted before what was going through the console window. But to clarify there is nothing special or abnormal scrolling through my console window when this occures. Just that everything that is scrolling through it is significanlty behind.

Stuff I consider abnormal
arq seq give up ...
Bad packet ... CRC ...

I do get the occational bogus data - Item removed from zone, but got an update for it - But I can force one of those just by looting my corpse quickly enough after getting resurected.

~ TK