Killing Floor Dedicated Server Internet Optimization

Strong hardware and a fast internet uplink do not automatically make Killing Floor smooth. An Unreal Engine server can show good ping in the browser while players still see jitter, ping spikes, packet loss, phantom hits, and map-travel disconnects.

The goal is to show KF1 admins how to read network stats, where to look for bottlenecks, and which IpDrv.TcpNetDriver settings are worth changing.

First things to check

Symptom	Check	Tool
Ping jumps for everyone	CPU tick time, tickrate, outgoing bandwidth	`stat net`, `inject userflag 1`, CPU monitoring
Packet loss for one player	route to server and local player network	`tracert`, PingPlotter, `stat net`
Packet loss for many players	server uplink, redirect, tickrate	server monitoring, `bytes/sec`, `packets/sec`
Hits feel like they do not register	ping, packet loss OUT, server authority	`stat net`, client FPS
Slow connections	downloads, redirect, `InitialConnectTimeout`	`IpDrv.TcpNetDriver`, HTTP redirect

Start with diagnostics. Blindly raising NetServerMaxTickRate often helps some players while making the server worse for everyone else.

1. Ping, latency, and bandwidth

Online play depends on two different things:

latency - how long a packet takes to arrive, usually felt as ping
bandwidth - how much data the connection can move per second

High bandwidth does not guarantee low ping. You can have a fast uplink and still have a bad route to a specific player. That is why “the server lags” should be checked with route quality, packet loss, and server load, not only internet speed.

2. Tracert and the route to the server

If only some players have the problem, ask them to test the route:

tracert server-ip-or-domain

What to look for:

a sudden latency jump at one hop
packet loss at an early hop - often player-side or ISP-side
packet loss at the final hop - possibly server or hosting-side
long international routes - good local bandwidth does not guarantee good cross-region play

For longer tests, PingPlotter or a similar tool is better than tracert, because tracert is only a snapshot.

3. `stat net`: main in-game diagnostic

Open the console and run:

stat net

Important fields:

Field	Meaning
`Ping`	game latency, not always the same as ICMP ping
`Channels`	relevant actors the server tracks for this client
`Unordered/sec`	packets that arrived out of order
`Packet loss IN`	loss from server to client
`Packet loss OUT`	loss from client to server
`Packets/sec`	packets per second
`Bunches/sec`	actor updates per second
`Bytes/sec`	actual data flow
`Netspeed`	client connection speed cap

Packet loss should be 0. Occasional spikes happen, but a constant nonzero value means the player is missing game information in one or both directions.

4. Why F1 ping and `stat net` differ

The scoreboard ping and stat net ping are calculated differently. Client FPS, server tickrate, and packet timing all affect the result, so F1 can show a nice number while the game still feels bad.

For diagnostics, prioritize:

packet loss IN/OUT
bytes/sec compared with netspeed
packets/sec compared with tickrate
stable client FPS

If client FPS drops below incoming packets/sec, the player may feel “invisible packet loss”: packet loss stats look clean, but packet processing falls behind.

5. `inject userflag 1`: tickrate and CPU-time

For deeper testing, enable userflag:

inject userflag 1

Disable it with:

inject userflag 0

This can expose maximum tickrate and last server tick time. Use it only for diagnostics: it adds extra traffic and is not needed during normal play.

CPU sanity check:

net + act << 1000 / tickrate

Example: at tickrate 50, one tick has a 20 ms budget. If net + act regularly gets close to 20 ms, the server cannot reliably hold that tickrate.

6. Base `IpDrv.TcpNetDriver` block

The main settings live in KillingFloor.ini:

[IpDrv.TcpNetDriver]
AllowDownloads=True
ConnectionTimeout=15.0
InitialConnectTimeout=150.0
AckTimeout=1.0
KeepAliveTime=0.2
MaxInternetClientRate=10000
MaxClientRate=20000
SimLatency=0
RelevantTimeout=5.0
SpawnPrioritySeconds=1.0
ServerTravelPause=4.0
NetServerMaxTickRate=30
LanServerMaxTickRate=35
DownloadManagers=IpDrv.HTTPDownload
DownloadManagers=Engine.ChannelDownload

7. What is actually worth changing

Setting	Practice
`MaxInternetClientRate`	Usually `10000-15000`; higher only when clients and uplink are stable
`MaxClientRate`	LAN limit, `20000` is fine
`NetServerMaxTickRate`	Main smoothness and load setting
`LanServerMaxTickRate`	For LAN or private low-ping games
`InitialConnectTimeout`	Lower only for specific stuck-connection problems
`RelevantTimeout`	Usually keep `5.0`
`SpawnPrioritySeconds`	Usually keep `1.0`
`ServerTravelPause`	Usually keep `4.0`

MaxInternetClientRate caps server-to-client traffic. It does not fix a bad route from client to server and does not solve packet loss OUT.

8. Tickrate starting points

Tickrate is server FPS. Higher tickrate means the server accepts and sends updates more often. It can improve responsiveness, but it increases CPU and network load.

Server type	Starting tickrate	Notes
6 players, normal KF	`30`	Good baseline
12 players	`40`	Watch `bytes/sec` and packet loss
12 players, strong clients	`45-50`	Only if players have no loss
20 players	`50-55`	Needs good CPU, bandwidth, and testing
International server	`30-40`	Routes matter more than theoretical speed

For heavily-modded servers, high zed counts, or mutators, start lower. More actors means more Channels and Bunches/sec, which means more data per client.

9. How to spot an excessive tickrate

Tickrate is too high if:

Packet loss IN appears for several players at once
Bytes/sec regularly hits Netspeed
ping rises during late waves
CPU tick time gets close to the tick budget
players with clean routes start reporting jitter

Lower NetServerMaxTickRate by 5 and test again.

10. Windows and Linux servers

Older Unreal/UT Linux servers could send packets less consistently relative to NetServerMaxTickRate, even when CPU was not maxed out.

Practical takeaway:

do not judge the server only by configured NetServerMaxTickRate
watch actual packets/sec
test late waves, not an empty server
if a Linux instance behaves oddly, compare it with a Windows instance using the same settings

Modern hosting may behave differently, but the diagnostic principle is the same.

11. Downloads and HTTP redirect

AllowDownloads=True is needed for custom content, but large maps should not be served by the game process. When a player downloads a map directly from the server, they compete with active players for bandwidth.

Use HTTP redirect:

[IpDrv.HTTPDownload]
RedirectToURL=https://example.com/kf-redirect/
UseCompression=True

If redirect causes version errors, check that redirect files exactly match the server files.

12. Client settings still matter

Even a perfect server cannot fix bad client netspeed, weak FPS, or background software.

Players should check:

background downloads, VPN, overlays, recording software
firewall and antivirus inspection
network adapter or Wi-Fi driver
real route to the server
stable FPS above incoming packets/sec

For old DSL/ISDN-class connections, too high client netspeed can create more traffic than the line can reliably handle. For modern connections, server caps around 10000-15000 are usually enough.

Recommended public server profile

[IpDrv.TcpNetDriver]
AllowDownloads=True
ConnectionTimeout=15.0
InitialConnectTimeout=150.0
AckTimeout=1.0
KeepAliveTime=0.2
MaxInternetClientRate=10000
MaxClientRate=20000
SimLatency=0
RelevantTimeout=5.0
SpawnPrioritySeconds=1.0
ServerTravelPause=4.0
NetServerMaxTickRate=30
LanServerMaxTickRate=35
DownloadManagers=IpDrv.HTTPDownload
DownloadManagers=Engine.ChannelDownload

Then raise NetServerMaxTickRate gradually: 30 -> 35 -> 40 -> 45 -> 50, checking stat net, packet loss, CPU tick time, and player reports after each step.