PDA

View Full Version : Intensive map cycle



legacy-dalfz
03-14-2005, 04:10 AM
Hi :D
I notice that during a map cycle on a server, the cpu usage jumps up and stays at 90-100% for about 10 seconds. If I run more servers on that machine, users currently in a game will experience a few lag spikes in this period. :eek:

It doesnt seem like epic has thought of this at all? Maybe it would be enough to lower the priority of the process during the map cycle. It wont't be difficult to solve this, but I think epic has to do it....or anyone got a solution?

-d :bulb:

buttpirate
03-14-2005, 09:49 AM
Originally posted by dalfz
Hi :D
I notice that during a map cycle on a server, the cpu usage jumps up and stays at 90-100% for about 10 seconds. If I run more servers on that machine, users currently in a game will experience a few lag spikes in this period. :eek:

It doesnt seem like epic has thought of this at all? Maybe it would be enough to lower the priority of the process during the map cycle. It wont't be difficult to solve this, but I think epic has to do it....or anyone got a solution?

-d :bulb:

Yes, they have thought a lot about this problem. The best way to minize this is to ensure you have more than enough horsepower in your system..

legacy-dalfz
03-14-2005, 10:40 AM
Do you have any references on this I can read? :)


-d

legacy-hmishima
03-14-2005, 11:34 AM
What is your machine and what are you running on it - gametype and player count?

QettoE
03-14-2005, 12:35 PM
Map cycle is just like a server start, no or very minor difference. That's why CPU utilization is very high at that moment.

QettoE

legacy-[Fragism] hiryu
03-15-2005, 10:58 PM
Originally posted by dalfz
It doesnt seem like epic has thought of this at all? Maybe it would be enough to lower the priority of the process during the map cycle. It wont't be difficult to solve this, but I think epic has to do it....or anyone got a solution?
It won't help as much as you think. Priorities affect the amount of CPU given, but not when. The problem is map loads are resource-bound, so they will run until the OS preempts them (50 - 150 ms, depending on OS), and pseudo real-time processes will starve in the mean time. Scheduling latency under pressure is a doctoral thesis type of problem space.

The solution is to have multiple run queues (multiple CPUs and/or HT) where tasks can 'seek refuge' from the map load. HT doesn't do much for throughput (what benchmarks normally test), but it's great for latency.

legacy-dalfz
03-17-2005, 03:17 AM
You are right.

You're saying that ucc-bin spends time in real-time priority resource-bound syscalls (which in this case must be disk access, what else?). That confirms my suspicion, and means the code for loading new maps is not designed to handle this - at least not good enough. It is not hard to write code that spends much less time in the kernel before it gives away its timeslice. Basically it means to load a file in small chunks and sleep after each. Sure, loading would go slower, but that's much better.

Oh by the way, for those who can spare some memory (imo the cpu seems to be the bottleneck over memory), why not make the game configurable to launch a separate thread that will load the next map nice and slow while the current game is on-going?

-d

legacy-[Fragism] hiryu
03-17-2005, 04:01 AM
The game play is pseudo real-time -- it doesn't need a lot of CPU as much as it needs time right when it asks for it. Map loads are resource-bound -- it will hog the CPU as long as the OS will let it. That's fine when you only have one game on the box, which is the primary audience. Sipping in the next map during current game play (willfully surrendering the CPU) would work. Making UT behave on higher priorities (so it can just kick the map loader out of the way as needed) would also work.

legacy-dalfz
03-18-2005, 11:39 AM
Making UT behave on higher priorities (so it can just kick the map loader out of the way as needed) would also work.

Sorry, but I don't see how that would work? As I see it, it would be the same as my first suggestion - the maploader would surrender user time, but not system time (which is critical in this case). Or am I missing your point?

-d

legacy-[Fragism] hiryu
03-18-2005, 05:52 PM
The system/user separation doesn't really make a difference. An all-userspace task, like SETI@home, will have the same effect.

When your turn on the CPU comes up, the OS will let you run until you run out of stuff to do (sleep), block on something long-term (disk IO), or use up your alloted time (preemptive multitasking). During game play, UT will churn out a frame for a few ms, then sleep for a bit. Multiple servers all do that, so a game can generally count on getting scheduled within a few ms of their wake-up time.

Things get fun on a map change, though, since that's sometimes in the blocking group, but mostly in the preempt group. When their turn comes up, they ride the CPU for about 100 ms, when the OS kicks them off. In the mean time, all of the other games have woken up and are waiting to be scheduled. They have the same priority as the map changer, though, so they don't have any right or ability to kick the CPU hog out of the way. So they wait. Since the scheduling latency goes from around 0-10ms to 0-100ms, it's no surprise your ping starts flopping around like a fish.

HT helps here because the map changer will still drag on the CPU, but it can only clog one scheduling queue. The games will take longer to churn out their frame, so latency goes to around 0-20ms, but that's still much improved.