I’ve expanded my services
Support for the following OS’s
- CentOS
- Fedora
- Gentoo
- FreeBSD
- NetBSD
Features for Linux
- Optimized kernel package with different headers
- Optimized i686 glibc packages for x86_64 that are faster and lower CPU usage on large servers. I have personally used these in production and they are much faster. As soon as I have enough time, I’ll post some benchmarks (I/O etc)
- PaX / SSP / Security Packages available (BETA)
- uboost plugin that optimized gameservers:
– SSE2 memory copies
– Userland timecounter support. Avoids overhead calling time over and over and caches last timestamp if it hasn’t changed and uses that value.
– Free updates, access to beta test code, and newer kernels. Unlimited support.
Features for FreeBSD + Linux emulation
- Custom rewritten timecounter code that gives very excellent tickrate / FPS behavior
- SSE2 based bcopy/bzero support
- A bunch of other things 
Pricing for all services:
$99 USD one time fee. Refunds are NOT available, but I’ve never had a request for a refund.
Game Stuff
Is FreeBSD, or even newer versions of NetBSD. FreeBSD will busy wait on sleeping, so you get more accurate timing. Linux is okay, but I don’t really like using it for game server hosting due to each kernel
having newer bu… err features than previous ones.
The problem with any of the linux binaries is they consume large amounts of CPU compared to their windows counterparts, plus they aren’t as optimized. Alfred from VALVe spoke with me and said they won’t move to a newer GCC because it breaks so many mods.
Game Stuff
I’m on my way out of cPanel, I put my 2 weeks notice in. There’s a position opening up here at the hospital for a senior systems admin, which fits my repertoire quite well. I need the additional cash to dump into my next exciting projects. The schedule is MUCH MUCH more compatible (days, m-f) plus it would allow me to put that under my belt.
I’m still offering consulting work to people who need to have some ‘tuning’ done to their respected server (kernel, os, etc). I have my own packages available, such as optimized glibc (omit frame pointer removed), real time kernel with 32bit vsyscall support. Message me on IRC (gamesurge) under “Monk” if you’re curious. I do obey confidentiality to people I do business with, so if you’re a GSP and you need some help, let me know. My fees are reasonable and my reputation is unmatched.
- Linux
- FreeBSD/NetBSD
- Windows support (minimal)
Game Stuff
Tired of high CPU usage on source servers in pubs? (24+ slots) Tired of choke/loss/bad reg on large servers?
I present a module that was written to combat excessive CPU usage.
Features:
- Rewrites the game’s functions to use a CPU instruction to get time
- Rewrites some of the core functions that are processed each frame to use a more relaxed sleeping (5 to 10ms sleeps, which is 500fps for 5ms or 100fps for 10)
- Rewrites specific glibc functions for speed, no accuracy
- Forces the use of SSE2 instructions for memcpy’s/memzero
- Other fixes
Before’s and Afters:
A 32slot source server with 31 bots running random patterns generates approx. 80% mean and 99% peak cpu usage. This module reduces the CPU usage to 45% mean and 60% max (data is coming)
Cost: $99 (one time fee)
OS’s supported: FreeBSD, Linux x86/x64
Status: Almost done
Want it? Contact me here or message me on gamesurge.
Game Stuff, uboost
A topic on VAVLes mailing list:
To: "Half-Life dedicated Linux server mailing list"
<hlds_linux@list.valvesoftware.com>
Subject: Re: [hlds_linux] sourcetv causing server side fps issues
Linux srcds has used a ton of CPU forever. The main frame loop is
optimized for a windows 66hz timer environment. Hence, linux servers
are 'perma-boosted' and chug inordinate amounts of CPU for minor FPS
increases, and they give us no variables to tweak the various sleep
times/calculations that impact this. SSE2 is still broken in linux
srcds. it also uses gettimeofday heavily, which was bad enough that
the l4d team specifically redid that part of the engine. The engine
uses 2-3% of the CPU entirely idle on kernels with a high response
rate (HPET/1000hz/other common things), which caused the l4d team to
put in a hibernation mode.
The x86 binaries still use -fPIC
On other arches (amd64) it don't have any performance advantage due to
the necessary calls being there, but on x86 PIC clobbers a register
and causes call heavy binaries like srcds to use upwards of 6% of
their CPU time on thunks. Nvidia's linux OpenGL library, mpeg
decoders, etc, all use non-fPIC shared objects on x86.
And yeah, SourceTV murders my server in CPU usage. I also noticed FPS
dips to the point where I had to fuck with the sleep timer to make
things go smoothly. I made a few threads about this but valve isn't
really all that interested.
- NephMy response is
64bit binaries would help. I've just finished porting vsyscalls back
to 2.6.24 series (x86), and I see a minor drop under load. However,
it doesn't fix the fact
that the engine spends about 1500 cycles an idle loop with source tv
on. I've also hacked in CLOCK_MONOTONIC support instead of
gettimeofday.. why does a gameserver
need nanosecond timestamps if everything is more or less estimated?
I didn't think clobbering 1 additional register would make that much
of a difference. Maybe on older gcc versions, but newer ones are better at it..
however, -fPIC will turn off optimizations that otherwise have to be
enabled.. I think valve is using 2.9.5 on 1.6/source.
The best long term solution is to use AMD64 binaries again, and then
they could probably use fPIC without worry about clobbering %ebx..
Windows has better binaries. Linux has a more customizable userland/kernel. Clobbering %ebx may give lower performance under load; HOWEVER. I think the best bet is to adopt 1.6′s behavior and host the sourcetv separately. Too much context switching when it’s enabled.
Pick your poison.
Game Stuff
Throwing more fps to the gameserver doesn’t fix the fact it sucks under load, due to the usage of horrible APIs.
They are more or less lying about the FPS by making nanosleep wake up early. I doubt they are running their clock interrupt at 12K.
let’s say the game requests a usleep(1000) and it won’t wake up for about 7-8ms due to scheduler latency. well, they basically made usleep(1000) return about 100 or so, which is lying to the engine.
A kernel running at 1000hz should give about 1000fps or so (erroring is about 5 to 10%), so how is it a gameserver can run higher than the HZ of the system? clock aliasing? … they are lying about when to wake up.
There are some patches out there to allow more than 1k for interrupts. This has a side effect of cache line ping pongs and other horrible behavior like clock skewing, and clock drifting..
Bottom line, you won’t notice a difference between 2000 and 12000. And, if you are able to run your clock interrupt higher (a couple of providers I know can do this) then it isn’t lying, it’s more or less correct; but you are talking about microsecond improvements in frame time.. a human can’t tell the difference between a microsecond and a nanosecond.. This is mostly bullshit marketing. I’ve had the engine cranked up so high that all excess CPU cycles were busy waking up *exactly* as requested, regardless of scheduler latency. This gave the best behavior, serverside, but the most cpu usage.
After about 3128fps on Source, the engine’s positives turn negative due to all the problems I mentioned previously.
Instead of doing all that horseshit, fix the APIs in the game.
Drama, Game Stuff
Customer B complains that his teammates can’t kill anyone. Provider A checks on machine. Machine is green/green/green (load, network, etc)
Provider A goes into server. Provider A can kill someone with a weapon. Customer B tries to kill provider A. Provider A has 10 life left. Customer B says “THAT WAS A FUCKING HEADSHOT” . Customer B proceeds to say the server is junk. Provider A looks at the hlstatsX logs showing hit location etc. Provider A sees that he aimed at the chest.
End result? Either 1.) the user keeps fucking with interp settings making the game out of sync with other users or 2.) he aimed at the head and there was a prediction error.
:p
Game Stuff, Misc
Left 4 Dead only requires a 30hz system interrupt clock at the minimum to operate. High resolution timers for the game are useless and do nothing but fire off interrupts so often.
Just reduce HZ to 100 for the best possible CPU usage, and optimal performance.
Game Stuff
Punkbuster is supposed to be the defacto cheat detection for games..
The biggest ‘flaw’ with PB is it’s banning. It bans cheaters.. while this may seem OK to some of you, public humiliation is not the answer. If I were to go get kicked/banned for cheating in a PB enabled game, I would be posted on one of the few anticheat sites with people slandering me etc.. Then I would go buy another key/game/whatever and continue to hack because I was publicly humiliated. Anticheat sites are full of paranoid people who look at everyone as a cheater.
Instead of wasting time banning cheaters, why don’t you stop cheats from working. I did it in OSP, and some games aren’t easily hackable. Banning cheaters is a waste of time, stopping cheats from working is more worthwhile than the former.
VAC2 has the right idea, sorta, with delayed banning. But it doesn’t solve the technical problem of flawed APIs that can be used to write whatever hacks.
The only way you are ever going to stop anyone from cheating is prevent them from reading and writing to memory.
-M
Game Stuff
I have a field tested kernel for linux that summit has to use for one if it’s hltv machines. I was using it to provide some newer games (L4D) instead of upgrading my FreeBSD machines to include newer linuxolator stuff.
Anyways, I’ve modified it to suit gameservers. I field tested it and the FPS is pretty stable, if anyone wants it just let me know (yes, I’m serious)
Features:
Realtime Scheduler
Fixed some bugs in the timer routines to not add 3 jiffies
Added some other enhancements
Attempted to reduce how much latency usleep returns. This should fix the jitter on FPS stats on source.
Mark the TSC as useable *only* on Intel processors. Use HPET on AMD gear.
Disable some stuff that doesn’t need to be enabled (cpufreq, acpi processor stuff, etc)
ToDo:
Add vsyscall support for x86. This will map a shared page into every process running and allow a syscall without the overhead of an interrupt. Should allow low overhead gettimeofday() calls.
Code, Game Stuff, uboost