Quake runs 100% CPU, why?

[PalaceGerbil]

Quake 2 runs at 100% CPU for me .  Server and client.  Urban Terror and Q3 also run like this.

The only way I've been able to reduce the CPU usage is by running an init.d script that backgrounds the execution.  At which point it it leaves the CPU rather cold.  I can't say that it ran better like that.  Oh yeah, I couldn't jump up on top of a box.  Like as if I were somehow shrunken by 10% -- but there was something I rather liked about it.  I cannot be playing with a disability. 

It's always 100% and it does not let go.  It looks very similar to RAM benchmarking.

Why is this?

I have a linux relatively up to date.

[The Happy Friar]

Strange, I didn't know Q2 was multithreading.    Mine never runs @ 100% on windows.  In Lunix can you change the affinity of a program to use less cores?  You could use that to see if it really needs all your cores or not.

[|iR|Focalor]

Quake 2 runs at 100% CPU

That... makes sense. My old computer started having cooling problems not long after I started playing Q2 online regularly. When I first got the machine, it was pretty quiet. I played a few offline games on it like the Return to Castle Wolfenstein thing that I was never able to play on my older Win98 machine. But when I started playing Q2 online, it wasn't very long after that when the fans started sounding like god damn leaf blowers. Part of it was just the noisy shitty fan on the video card, but part of it was also the CPU fan. At some point the fan at the rear of the case failed and I didn't know about it, and that caused the other two fans to run much heavier than they should've, and ended up damaging several different components. I remember people used to call me on the phone while I'd be playing and would ask me to turn off the vacuum cleaner while I'm talking to them. I was always like, "Dude, thats my computer.... I know, right?"

[haunted]

Install Windows ME and use the new holywater version. All issues should be resolved.

[quadz]

It's always 100% and it does not let go.  It looks very similar to RAM benchmarking.

R1Q2 server on Linux uses close to 0% CPU when idle. And even during rare events with 40 players on the server (like the Q2 15th anniversary FFA bash) it still uses less than 50% of a single core.

Which version of Q2 are you running on your server?

[ex]

Long shot, but... maybe try a virus/rootkit scan?  Sometimes when you get some bug on your PC, its goal is just to fuck up your computer in any way it can.

[The Happy Friar]

Virtually all Q2 clients and servers are single threaded. I have never heard of anyone making a multi-threaded version.

That's why I thought doing something with the affinity might show it's not a Quake issue.  It shouldn't be using more then 50/33/25/etc. of CPU usage on a multicore system.  No system specs presented though, so he COULD have a Pentium MMX, 2, etc.

[PalaceGerbil]

When I say %100 cpu I refer to one logical processor unit.  On my single core its one hyperthread.

The only thing I could get out of strace that seems to occupy the majority is

"gettimeofday ({##,##}, {###,###})" = 0

# being numbers.  Which is very similar to KDE traces which are usually filled with those gettimeofdays.  KDE is C++ but I think it is the libc time getting function.  KDE does not run 100% but then again the gettimeofday's are slightly less frequent and they subside to some extent eventually.  Makes it very difficult to trace bugs.

In Q2 they appear in blocks of about 20 gettimeofday's.  There is also a

clock_gettime(CLOCK_MONOTONIC, {###,###}) = 0

also in blocks of 10-20, interspersed in the trace that does appear to be overtly connected with the gettimeofday.


When I run on the run level daemon, the daemon handler probably some how puts a check on the  gettimeofday  function through libc.  It probably running in between the program and the libc.  Its job is to handle these things after all.

Which may explain why when I run under the daemon -- I can't jump very high.  Sort of.


Urban terror also runs in a similar fashion.


All this is fine by me anyways, I was just wondering if there was conclusively a rational for running consecutive calls to the time.  Which if you did not know happens during server client sync.  Maybe in other instances.  Perhaps several functions all call for time and the time calls all get executed at once.  Which would mencingly  suggest its ease of aggregation in one single time call with 0 rewrite.   No?


Other interesting things in strace.... when handswitching, you can see the array search of the the config settings for the static change on the local client.  It searches until it finds it.  So if this and other game action sets where on top it would perhaps leave open the possibility of slightly optimized usage.  Although the overhead for that array is nearly nil it is getting stronger everyday.

[|iR|Focalor]

If you are seeing 100% CPU usage in Windows on an idle Q2 server then you have screwed up your Windows scheduling or messed with the code in Q2 to cause it. Either that, or your running a computer from 1986.

Yeah. What he said.

Bottom line, if your computer is having problems running Quake2... take a big fucking hand cannon of a  pistol, shoot your computer 3 or 4 times, toss it out the back door as far as you can, then go buy another computer. And then try not to fuck the new one up like you obviously did the last one. Because if your computer can't run Quake2, then chances are real good that it can't run a lot of other shit either, in which case it's an outdated and useless fucking paperweight.

You can actually get a decent brand new modern computer for pretty cheap these days. Used to, you'd be looking at 2 grand or more for something up to date. You can find one now for 500 or less. It might not have the special doo-dads and outrageous specs that give nerds raging boners, but for everyday home use, it'll get the job done. And it's a helluva lot better than pulling your hair out for hours and days on end trying to fix something that refuses to cooperate.

[QwazyWabbit]

When I say %100 cpu I refer to one logical processor unit.  On my single core its one hyperthread.

The only thing I could get out of strace that seems to occupy the majority is

"gettimeofday ({##,##}, {###,###})" = 0

# being numbers.  Which is very similar to KDE traces which are usually filled with those gettimeofdays.  KDE is C++ but I think it is the libc time getting function.  KDE does not run 100% but then again the gettimeofday's are slightly less frequent and they subside to some extent eventually.  Makes it very difficult to trace bugs.

In Q2 they appear in blocks of about 20 gettimeofday's.  There is also a

clock_gettime(CLOCK_MONOTONIC, {###,###}) = 0

also in blocks of 10-20, interspersed in the trace that does appear to be overtly connected with the gettimeofday.


When I run on the run level daemon, the daemon handler probably some how puts a check on the  gettimeofday  function through libc.  It probably running in between the program and the libc.  Its job is to handle these things after all.

Which may explain why when I run under the daemon -- I can't jump very high.  Sort of.


Urban terror also runs in a similar fashion.


All this is fine by me anyways, I was just wondering if there was conclusively a rational for running consecutive calls to the time.  Which if you did not know happens during server client sync.  Maybe in other instances.  Perhaps several functions all call for time and the time calls all get executed at once.  Which would mencingly  suggest its ease of aggregation in one single time call with 0 rewrite.   No?


Other interesting things in strace.... when handswitching, you can see the array search of the the config settings for the static change on the local client.  It searches until it finds it.  So if this and other game action sets where on top it would perhaps leave open the possibility of slightly optimized usage.  Although the overhead for that array is nearly nil it is getting stronger everyday.

Oh. You're on Linux. I didn't notice that fact before but I don't think you mentioned it originally.

Build a non-debug version of your client and run it outside KDE. Strace uses lots and lots of CPU to trace your program and isn't intended to be running except for detailed debugging. Asking why your client uses 100% CPU in strace mode is like asking why is the sun hot... answer: it does that.

As for the rest of the above quoted text. WTF are you talking about, dude?

[yahoo]

just use winxp as a server or client.

Should you insist, why not run a dedicated Linux server? would be more efficient that way.

[Jay Dolan]

So.. a couple of things here:

1) The Quake2 client should use 100% CPU if you're spawned and playing. Especially older clients. Almost all of them have a busy-wait loop (that gettimeofday() thing that PalaceGerbil mentioned). Basically, Quake2 only has millisecond precision for frame intervals. Therefore, if your machine is capable of > 1000fps, the main loop in Quake2 will sit on gettimeofday() until 1 millisecond has elapsed since the previous frame. Almost all modern computers can easily hit 1000fps in Quake2.

2) 100% CPU utilization is not a bad thing when playing a game. You're not gonna hurt your computer's feelings, it's not gonna get tired and walk off the job. Basically, don't sweat it. It's doing precisely what the fuck it was built to do. And yea, remember, we're talking 100% of one core, because Q2 engines are not multithreaded.

3) Except Quake2World, which actually does use as many cores as you have. Unfortunately, there's only so much work that can be parallelized in Quake, and so YMMV in terms of performance gain. On some maps, especially those with weather effects, having at least 2 threads is helpful. And having 2-4 threads never results in a lower framerate.

4) If your Quake2 *server* is using 100% CPU when idle, it may be starving for I/O. You mentioned something about backgrounding the process. Try running it through `screen`. That will give it proper stdin/stdout/stderr file descriptors while you can detach from it, logout, whatever. It's been the preferred way to run Quake servers since NetQuake.