I'll also hope that they will implement multicore/multithreading.. But anyways, thumbs up for this, looking forward to more optimizations!
/Chris Sent from my iPhone 4 Den 29/06/2011 kl. 03.06 skrev Gary Stanley <g...@velocity-servers.net>: > At 04:16 AM 6/28/2011, Henry Goffin wrote: >> Hi all - >> >> Free to Play brought a huge influx of new users to Team Fortress. To help >> server counts scale up to match the demand, we are reworking the dedicated >> server for performance. We want to improve player responsiveness as well as >> to reduce CPU usage so that hosts can run more servers per physical server. >> >> Some of those changes addressing CPU usage went out last night. Server >> operators should see a big decrease in CPU load and can potentially run more >> instances per physical box now. However, a side effect that many of you have >> noticed is that server FPS has an effective cap of 500 instead of the >> previous 1000, or possibly even lower than 500 depending on your Linux >> kernel HZ setting. This should not have a noticeable impact on gameplay as >> the tick rate is still locked (well, mostly locked) at 66 updates per second >> and the frames that are being dropped are "empty" frames that do not >> actually run a server tick. > >> We're going to address this further in another set of performance >> improvements. Sorry for the temporary confusion, but we wanted to get these >> CPU load reduction changes out quickly to help with the Free to Play user >> crush. > > How about some native 64bit binaries? Using shared objects clobbers the ebx > register on 32bit. > >> Longer term, we want to move away from FPS as a measure of performance and >> instead show actual load and responsiveness (jitter/latency) statistics. The >> difference between a tick and a frame is complicated, and fps_max sometimes >> affects performance in counter-intuitive ways. We would like to retire >> fps_max for servers and replace it with a more obvious server performance >> setting. We'll give you all a heads up before we do so. > > > Please also add bounds checking to the usleep call prevent fictitious values > from inflating the server's FPS, causing idiots to sell super high FPS that > does nothing. I have some code if you want to demonstrate this behavior. > > > > <gary at summit-servers dot com | gary at DragonflyBSD dot org> > http://leaf.dragonflybsd.org/~gary > > > > > > > > > > _______________________________________________ > To unsubscribe, edit your list preferences, or view the list archives, please > visit: > http://list.valvesoftware.com/mailman/listinfo/hlds_linux _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
