[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
>lower it.
>
>
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
broadband users).
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
bigger packets?
>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.
>--ryan.
>
>
I'm really glad you use two dashes, 'cause I've never used more than one. =P
-ryan
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
mailing list