[Fwd: Re: [bf2ranked] Overshot frames and CPU usage]
"Einar S. Idsø"
esi at itk.ntnu.no
Tue Oct 11 04:23:48 EDT 2005
-----BEGIN PGP SIGNED MESSAGE-----
This mail is the result of a discussion on the BF2 ranked server
provider list. It concerns the influence on jiffies - the scheduler Hz -
in Linux on the BF2 server performance. I thought the results might be
of interest to people on this list who run Linux-servers as well.
First follows an introduction for this list. Below that is my original
mail as sent to the ranked list.
Having been troubled with people complaining about lag on our servers
while the servers were running at 50-70% CPU-load, we have been looking
into alternative reasons for the lag. In addition to the obvious ones
such as client-lag and network-problems between client and server, we
stumbled upon another potential reason for lag specifically for
As we all know, the BF-series uses significantly more CPU under the 2.6
kernel than under 2.4. The reason for this is the fact that the 2.6
kernel by default performs task-switching at a frequency of 1000Hz,
while the 2.4 kernel does the same at 100Hz. Well, that's not really the
real reason since I know of no other program that exhibits this
difference in behaviour. Obviously there's something fish in the way BF2
schedules, but the point is that by reducing the scheduling-Hz, called
jiffies, one can reduce the CPU-load of the BF-series games. In order to
reduce CPU-load we reduced the jiffies to 200 ("define HZ" in
/usr/src/linux/include/asm/param.h, recompile kernel), going from ~8%
CPU-usage to ~1% with an empty server on an Opteron 2.4GHz. We should
NOT have done this :P
In the BF2 server console one can see the following at the top right:
Average FPS: 34 [d:0, o:32]
The FPS is the number of server updates performed per second. The d
indicaties dropped frames (the server can't keep up), while the o means
overshot frames (gameticks and physics ticks go out of sync). On our
servers we observed the o-value going into the hundred thousands,
typically increasing by 2-3 values per second. The FPS was also stuck at
around 30. This happened because the scheduler, running at 200Hz,
doesn't switch tasks at a high enough resolution to produce a steady
frame-output at a higher FPS. I therefore tried out different Hz-values
in an attempt to look for the "optimal" jiffies for a BF2 server
platform - combining high FPS and no unnecessary overshot frames with
low CPU usage. The results follow below.
Results as posted to the BF2 ranked list
Here are the results of my tests.
On a dual Opteron 2.4GHz, running a single idling 64-player server with
Operation Clean Sweep as active map, I get the following:
1000Hz: FPS at 34 80% of the time, 20% at 33. 8% CPU-usage
800Hz: FPS constant at 33 but dips to 32 on occasion. 7.5% CPU-usage
600Hz: FPS at 33 50% of the time, 25% at 32 and 25% at 34. 5% CPU-usage
500Hz: FPS at 32 80% of the time, 20% at 31. 6% CPU-usage
400Hz: FPS constant at 33 but dips to 32 on occasion. 7.5% CPU-usage
200Hz: FPS at 29. <1% CPU-usage. o-value increases by 3 per second!!!
To clarify: CPU-usage is always reported as the bf2 process's usage
according to 'top', so it is the %CPU of one of the two CPUs and not of
the whole system (which goes to 200%).
Different maps have different FPS. For instance, Sharqi Peninsula at
800Hz was almost constant at 34FPS but dipped down to 33 on occasion.
This was 1 FPS higher than Operation Clean Sweep in the same test above.
Mapchange results in about 10 overshot frames. Connecting players result
in 1 overshot frame. Except for this, rapid overshot frames were
observed with the 200Hz kernel, increasing in "groups" of three every
second (count quickly 3 upwards, stay steady, count quickly 3 upwards etc.)
Anything below 1000Hz results in moderately lower FPS.
200Hz results in massive overshot frames and 29 FPS - do NOT use this
In general, CPU-usage drops for lower Hz. 400Hz has an increase,
however. Possibly because of poor div/mod properties.
If the CPU-usage is critical, then 600Hz seems to be a rather good
choice. If it isn't then I would recommend 1000Hz.
Hope this is helpful to someone!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
More information about the Bf1942