[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