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.

Related pages

• Killing Floor Dedicated Server optimization
• How to host a Killing Floor Dedicated Server
• Package version mismatch
• Server browser and IPs