[ut2004] Is there any way to lower UT's priority when doing offline tasks?
J. Ryan Earl
heretic at clanhk.org
Tue Apr 6 21:03:22 EDT 2004
Ryan C. Gordon wrote:
>>Like changing maps? When UT changes maps, it eats all the CPU it can.
>>Is there anyway that we can lower ucc-bin's priority (ie nice it) while
>>it load maps and reset its priority when it's done loading? This would
>>help tremendously with multiple instances of a dedicated server running
>>on the same physical server.
>We've tossed around this idea, but haven't implemented anything. Unless
>you run the process as root, you can't raise your priority once you
Damnit, I didn't think about that. Time to whore the LKML, maybe
there's an easy way. When you nice a thread/LWP, it lowers the priority
of the parent process too?
As it is, I run UT with a priority of -1, and my other real-time stuff
gets a -2. This prevents the other processes from lagging, but
performance does not gradually degrade under load between different
processes; UT takes the sole hit. The other processes will all maintain
a response time of like 10ms, while UT goes up to 100ms server response
time; this isn't considering network latency (ie add 10-50ms for most
No other dedicated game servers we've put up have quite eaten as much
CPU on map changes. This has never been a problem before because it
never took more than a small fraction of a second to load a new map on
my hardware; literally like .2 seconds last time I timed it. Oh well,
I'm going with the time honored tradition of throwing more hardware at a
problem that a proper software solution. I'm about to move this onto an
Athlon64 3400+ and see how that fairs with the bigger caches and beefy
TLBs. Pentium4s SUCK under load.
As an added note, I can't seem to get the server latency on UT much
below 20ms. Even though it uses equal or less CPU time per client
connection as processes that respond in 3-10ms. I'm guessing UT uses
>We could throw some sleep() calls in there, perhaps, but that just
>increases level load time, which pisses off your gamers, too.
I think it's a shitty design for any dedicated-server to drop any
packets when loading resources personally; ie exactly like they all
freakin' do currently! I would call that a design error, though I can
understand it simplifies things quite a bit. Ideally, client and server
would each have a keep alive thread to maintain sync and still let
players communicate with each other. Yea yea, I know, thread/data
syncronization can be a bitch.
I'm really glad you use two dashes, 'cause I've never used more than one. =P
PS This is the best non-"id software" Linux game server I've dealt
with. The Battlefield source code must have made you wretch, and don't
get me started on Steam and Linux.
More information about the ut2004