[Fwd: Re: [bf2ranked] Overshot frames and CPU usage]

["Einar S. Idsø"]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi everyone,

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.

Introduction
- ------------
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
Linux-servers.

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.)

Conclusions:
Anything below 1000Hz results in moderately lower FPS.
200Hz results in massive overshot frames and 29 FPS - do NOT use this
setting!
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!

Cheers,
Einar
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDS3aUJ1Ofjl2c2/IRAkD6AJ0WoEjsmznrdkgke33FxGUiZf64IwCeK1tD
zkyaNGxU+cCmoaLNjNWp/oE=
=dpUt
-----END PGP SIGNATURE-----