Huge CPU utilization, more data...

[Yueh]

I ressurected the cpu utilization issue in the Help forum but I've got a little more info that might spark a thought in someone's head who knows the code much better than I

This is all with SEQ run from scratch with no EQ running at all. Just a black map window and nothing going on. Of course, with EQ running, it is still pegging the CPU.

I'm running the current Gentoo with QT 3.1.2-r3 and am seeing X burning 99% of the CPU when SEQ is running. If I resize the window by some marginal amount it tends to drop down into the 30% range. Same problem different millenia.

I did, however, find that if I get the map window down below 800x600 pixels, the X CPU utilization goes down under 5%. That might explain why a lot of people who could potentially have the problem don't see it.

I ran an strace on X in both states and it looks like X is getting interrupted by a SIGALRM polling loop. I would assume that is a map update loop or something. There really isn't anything out of the ordinary happening in X in either case, which I don't understand. I'll dig into the SEQ code and see if I can nail it down a bit but if anyone has any ideas let me know. I suppose I can drop my resolution so an 800x600 map is decent sized but I really like my huge spawn list

[Ratt]

If you know how, compile SEQ and enable profiling and see where the cycles are being sucked up into at different resolutions...

That would be a quick way to narrow down the search.

[Yueh]

Bah! I'm far from a Linux profiling expert but... I enabled profiling through ./configure --enable-profiling (rocket science there Ran showeq for a good minute. gprof counts calls but shows "no time accumulated." I'm assuming threading has something to do with it? Point me in the right direction and give me a gentle kick

[Yueh]

<--- Not real quick

The Gentoo glibc ebuilds disable profiling. Very nice.

Anyway, Here's the results, looks like that should point at something:

Good mode:

index % time    self  children    called     name
-----------------------------------------------
                0.00    0.00       1/4100        EQPacket::clientPortLatched(unsigned short) [279]
                0.00    0.00       1/4100        EQPacket::sessionTrackingChanged(unsigned char) [280]
                0.00    0.00       4/4100        EQPacket::seqReceive(int, int) [83]
                0.00    0.00       4/4100        EQPacket::seqExpect(int, int) [85]
                0.00    0.00       4/4100        EQPacket::numPacket(int, int) [84]
                0.00    0.00    4086/4100        EQPacket::qt_invoke(int, QUObject*) [1842]
[11]     0.0    0.00    0.00    4100         EQPacket::staticMetaObject() [11]
-----------------------------------------------
                0.00    0.00    4086/4086        EQPacket::processPackets() [13]
[12]     0.0    0.00    0.00    4086         PacketCaptureThread::getPacket(unsigned char*) [12]
-----------------------------------------------
                0.00    0.00    4086/4086        EQPacket::qt_invoke(int, QUObject*) [1842]
[13]     0.0    0.00    0.00    4086         EQPacket::processPackets() [13]
                0.00    0.00    4086/4086        PacketCaptureThread::getPacket(unsigned char*) [12]
-----------------------------------------------

Bad Mode:

index % time    self  children    called     name
                                                 <spontaneous>
[1]    100.0    0.01    0.00                 EQPacket::qt_invoke(int, QUObject*) [1]
                0.00    0.00   12307/12321       EQPacket::staticMetaObject() [9]
                0.00    0.00   12307/12307       EQPacket::processPackets() [11]
-----------------------------------------------
                0.00    0.00       1/12321       EQPacket::clientPortLatched(unsigned short) [285]
                0.00    0.00       1/12321       EQPacket::sessionTrackingChanged(unsigned char) [286]
                0.00    0.00       4/12321       EQPacket::seqReceive(int, int) [89]
                0.00    0.00       4/12321       EQPacket::seqExpect(int, int) [91]
                0.00    0.00       4/12321       EQPacket::numPacket(int, int) [90]
                0.00    0.00   12307/12321       EQPacket::qt_invoke(int, QUObject*) [1]
[9]      0.0    0.00    0.00   12321         EQPacket::staticMetaObject() [9]
-----------------------------------------------
                0.00    0.00   12307/12307       EQPacket::processPackets() [11]
[10]     0.0    0.00    0.00   12307         PacketCaptureThread::getPacket(unsigned char*) [10]
-----------------------------------------------
                0.00    0.00   12307/12307       EQPacket::qt_invoke(int, QUObject*) [1]
[11]     0.0    0.00    0.00   12307         EQPacket::processPackets() [11]
                0.00    0.00   12307/12307       PacketCaptureThread::getPacket(unsigned char*) [10]
-----------------------------------------------

[Laetos]

weird

i installed seq today just before patch on amd1800 kt266 with 750mb RAM and i had zero cpu performance was amazed (:

PS
- i had emerged newest xfree 2 days ago
- qt needed a recompile wouldnt want to start up seq
- seq coloured :P


PPS
i even run winex3.0 on another workspace to dualbox, odd thing there when i switched to seq workspace there was no update of my twink in the zone seq looked like not working, no clue how to fix this

[Yueh]

I updated world yesterday so I should be up to date. However, I did find that this only happens in 24bit or 16bit mode. 8bpp and I can't make it fail. Makes me think there is some sort of interaction with the Matrox driver. I'm running a Matrox G450. Used the stock Xfree driver as well as the Matrox driver, both have the same problem. DRI enabled or disabled doesn't seem to toggle it. Don't know. Given that X is eating the cpu and not seq I wonder if SEQ isn't filling an X queue somewhere faster than X can process it?

[Laetos]

oops forgot to say using a gts 2 32mb

did u emerge -u world --deep
?

[Yueh]

Hey! Lookie there, an xfree update Learn something new every day!

** runs off to look up --deep **

[Yueh]

Well, for the record, the latest Xfree didn't help. It just seems like it's hitting some threshold where X is not keeping up. I just have no idea what to twiddle with to narrow it down. Oh well, I suppose this one has been around for a LONG time...

... Ok, one edit before I give up. This cpu usage in X is caused by the bitBlt of the map. If the bitBlt copy to the offscreen tmpPix is commented out, the CPU usage can pretty much be toggled by resizing the window just a bit. Size doesn't matter and it seems like it's a 50-50 chance which state it lands in.. If both bitBlt's are commented out there is no problem. No surprise there.

Also, if the size of the map itself, the QPixmap that is, gets below 640x480 the problem goes away. One pixel on either side toggles the problem.

My guess is that it is a problem with the Matrox drivers and some preset buffer size that is flopping a bitBlt from hardware to software due to some memory limitation. But then, that is just a guess

If anyone who sees this high CPU utilization could post what graphics card they are using it would be helpful. If anyone has any suggestions where to go next, I'm all eyes I hate giving up!

[Ratt]

I have no clue where to tell you to go next. As you said, it sounds like a Matrox issue.

I'd like to see you put a different video card in there (like an NVidia because they have solid Linux drivers) and change nothing else and see if the problem is still there...

[icyman]

Minor input, just some data to add.

My SEQ box is now a celeron 900, 512MB ram, PCI GeF2MX400 (not 100% sure on the 400 - been a while since I opened her up).

Originally, I had Mandrake 9.0 + some security updates. I had downloaded Qt 3.1.2 and had it under it's own directory.

When SEQ was first back up & running on April 17th, I updated CVS, and started SEQ up. It decoded everything, and was running.... SLOWLY.

I did a top, and X was taking 90% of the CPU. Very odd I thought. Killed SEQ, and usage back down to normal. I ran SEQ again, same thing. Rebooted. X with SEQ was at 30%.

Couldn't figure it out after dinking around for a day, so I grabbed Mandrake 9.1, burned the 3 CDs, and did an upgrade (NOT a reinstall).

Unfortunately, I didn't watch X versions, nor libpcap, nor anything else that gets installed. Oh! I didn't (initially) change over to the Qt Mandrake 9.1 installed, so you can eliminate that.

I had recompiled SEQ after installing 9.1, before running it for the first time. Never had a CPU/lag issue since.

Not much for useful info, but more data to add to your proces of elimination - hopefully.


][cyman

[Yueh]

Yeah, I'm starting to wonder if there isn't some compilation order issue going on. Now that I've updated to the latest xfree I'm going to recompile libpcap and QT then SEQ and see what happens. If that doesn't fix it I'll swap video cards for another data point.

[Yueh]

As I was looking around at the SEQ code and QT API it occured to me that SEQ has quite a few QPixmaps floating around. Laetos and I both have 32Meg cards. Are we just running out of offscreen video memory? I recompiled SEQ to only use one map and that got me about twice the map size before it went south.

I wonder if QT is having trouble with DMA between some video cards so when bitBlt falls back to a memory copy, X takes forever dealing with it? I don't know the code well enough but are there any other big Pixmaps I could comment out?

[Dedpoet]

Ugh, FYI I kicked off my "emerge --update --deep world" yesterday afternoon around 4:00. It finished this morning around 8:30. That was on a P3 1.13 with 256 meg.

A lesson I learned, is if you run KDE and there is an update, make sure you manually unmerge your old version before rebooting or restarting your window manager. If you don't, all the links and libraries don't get updated properly and you end up with tons of errors and seg faults. I found a creative way to get a console open, did a "qpkg -I -i kde" to get the exact name of my old packages (kdebase-3.0.4-rc2 and kdelibs-3.0.4) and then unmerged them.

[Yueh]

That's the case with any dynamically linked app. If you use -u and --deep together you definitely better know what is about to happen or you run the risk of pulling the rug out from under your poor applications And on that note, I think I may just go run emerge world and see what happens to SEQ. Of course that will create about a million etc-updates I'd have to deal with...