This is intended to be a clearer, more focused version of this thread, with slightly more accurate information. That thread has also become extremely unwieldy and hard to find any any useful information or discussion in it other than the first post.

***
CG1 has been has been nice enough to code a web based rate calculator. You can find it at the following urls:

Note that the information in this thread is intended to be useful for server operators running servers on home servers running on broadband connections. Many will tell you that this isn't possible, or shouldn't be done, but I can assure you that it can be done, and you can run a server on a home broadband connection that runs well, and is fun. It won't be competition quality, but it should run well if it is configured properly and meets the minimum hardware requirements.

This thread is not for newbies. I don't have anything against newbies, I just don't have the energy or the inclination to write a newbies guide to setting up a Half-Life server. I am going to assume that you already know most of the basics of setting up a server. I am also assuming that you are running a dedicated server and that you are doing everything else that common sense dictates, such as not running p2p applications while you host your server, or downloading movies without appropriate qos.

Note that these suggestions are for Windows servers, not Linux servers. The hardware requirements for Linux servers are probably quite a bit less than they are for Windows. However, it should be noted that Half-Life, from what I have read, will probably run slightly better on a Windows server, than it will on a Linux server. This is not because there is anything wrong with Linux, but because HLDS hasn't been optimized properly to run at its best under Linux.

One thing I have discovered is that I can run a Linux server on the same connection, with a higher update rate. I don't know why this is. One theory is that it has to do with packet headers being handled differently on Linux and Windows server boxes, but for whatever reason, from my experience a Linux box will handle maximum update rates as much as twice as high as those that will provide good performance on a server running a Windows operating system.

Minimum hardware requirements for servers will depend on what game and mod you are running, and what mods you have installed. I have heard of Half-Life servers being run on Pentium III 600's, and even older hardware than that. I have personally run a small 12 person Half-Life 2 Deathmatch server on an Athlon 1200. The one thing I am sure of is that the hardware requirements are generally much lower than many would have you believe.

The next critical piece of the puzzle is the quality of your connection. You need to find out what your upload bandwidth is. You can generally find this information from your ISP, and you can confirm it with online bandwidth tests. The most important thing isn't necessarily how much bandwidth you have, but that your bandwidth is stable. You can test the stability of your connection by running a ping test on a reliable url, such as "www.google.com". You should run these tests at different times during the day and most especially during the "prime time" hours between 7:00pm and 10:00pm.

Which leads us to rates. Probably the biggest single mistake that server operators make is setting their various rates far too high. Many tend to think that in order for Half-Life to run well, you need to allow your clients 100 updates per second, and give your cients 20000, or higher, as a rate for bandwidth. We seem to confuse update rate with FPS, or somehow think the two are connected, so if we have a very low updaterate, the game will be choppy. Because of the way Half-Life is designed this is not the case. I have run a perfectly smooth running server with an updaterate as low as 4.

Having said all that, the most important cvars for running a lag free server are the following.

sv_minrate
sv_maxrate
sv_minupdaterate
sv_maxupdaterate

You will find these in your server.cfg file. If they aren't there, you will want to add them.

The first thing we will address is sv_maxrate. This is what controls the maximum amount of bandwidth each client can use. This rate is generally the rate that many will focus on, but it is nowhere near as critical to the performance of your server as the maximum update rate. However, it is still important, and setting it is fairly simple

The first thing you want to do before you determine your rate, is determine how many slots you should run, what your server size should be. Note also that your bandwidth requirements per client increase as your server size increases. I do not recommend a rate any lower than 8000 for a server size larger than or equal to 24, 6000 for a server size larger than or equal to 16, or 4000 for a server size larger than or equal to 12.

Note that the number your ISP gives you for your upload bandwidth will generally be in kbps (kilobits per second), or possibly in mbps (megabits per second). Half-Life and Source rates are in Bps (bytes per second). One byte is equal to eight bits. It is also a good thing to allow your connection some "head room" and not to max it out. 5% is a good number so I will multiply the available bandwidth number by .95 in all our calculations.

sv_maxrate 8000

bandwidth in kbps X .95 / 64 = recommended number of slots

sv_maxrate 6000

bandwidth in kbps X .95 / 48 = recommended number of slots

sv_maxrate 4000

bandwidth in kbps X .95 / 32 = recommended number of slots

sv_maxrate 3000

bandwidth in kbps X .95 / 24 = recommended number of slots

So if you have 1400 kbps in upload bandwidth available, and you are aiming for a sv_maxrate of 8000 you multiply 1400 by .95, then divide it by 64 to get a server size of 20. If your hardware can support it, on that connection you can run a server with 20 slots. This server should run well with an sv_maxrate of 8300 (see below for where I got this number).

Running backwards you can calculate your sv_maxrate this way.

sv_maxrate = bandwidth X 125 / server size

So if you want to run a 24 person server, and you have 1400 Kbps in bandwidth available, 1400 X 0.95 X 125 / 24 gives you an sv_maxrate of 6900 (note that this is lower than the minimum rate that I would recommend for a server of this size).

sv_minrate should always be set to 0, while sv_minupdaterate should be set high enough to prevent exploits, but low enough to not cause problems for clients playing on dialup. I would recommend 4. This will allow your dial up clients to set their update rate as low as they need to so that they can play with as little lag as possible. DIAL UP CLIENTS DO NOT CAUSE LAG, BAD SERVER SETTINGS CAUSE LAG. HIGH PING KICKERS ARE UNFAIR AND A LOAD OF CROCK! There, I feel better now.

The last thing to calculate is sv_maxupdaterate. This is the single most important server side rate setting. And this setting should be much lower than you might imagine.

The calculation that I recommend for sv_maxupdaterate is as follows:

sv_maxupdaterate = sv_maxrate / 300

So for the above sv_maxrate of 7466 you would divide that by 300 to get an sv_maxupdaterate of 24. Basically, start off with this formula, and if you are still experiencing lag spikes or high pings, adjust it downwards, one at a time, until you get stable pings that are as low as you are going to get on your server.

The formula I give for sv_maxupdaterate is very general, and in most cases it will probably give you an update rate that is lower than the highest rate your server can potentially handle. The best update rate for you will depend on your rate obviously, and also on your server size, as well as the mods you are running on your server. Generally the smaller your server size is, the higher your sv_maxupdaterate can be in relation to your server size. Also, the higher your sv_maxrate is, the higher your sv_maxupdaterate can be in relation to your server size.

For instance, this is all hypothetical, if you have a server size of 8 and a rate of 4000, your optimal sv_maxupdaterate might be 20, or 4000/200. However if your server size is 4, your optimal sv_maxupdaterate with the same rate, 4000, might be 26, or 4000/150. If you have a server size of 8 and an sv_maxrate of 8000, your optimal sv_maxupdaterate might be 53, or 8000/150.

The point is, that the only way that I know of right now to find your optimal sv_maxupdaterate, is to fill your server and see if your pings are stable and as low as they are going to be. If they are high and unstable, then adjust your sv_maxupdaterate down one at a time until your pings stabilize. If your pings are stable and as low as they are going to be, adjust upwards one at a time until they go wonky, then adjust back down to the last good rate, or perhaps two lower to allow for bandwidth fluctuations.

Its annoying, but if you can get a full server and people don't mind a few problems until you get things sorted, it won't take very long to get it right.

I really appreciate this. I just want you to know that you have helped me tremendously in learning how to operate a perfectly working server under Windows OS, and home connection. All my problems before were only caused from bots.

I want everyone here who reads this, if you have done what Drek has said, and you are running bots but still suffer from high pings/lag after doing everything in this guide, please check with your bot settings esp. with podbot because the latest version gives me unbelievable lag.

You are most welcome. It's nice to know my little novels helped someone. And yes, bots can cause problems. I used Sturmbot for several years, and it caused a lot of latency issues.

Bots take a lot of cpu time, and the more complex the a.i. for the bot, the more cpu time they will take, and it seems to me that Podbot has pretty complex a.i. And then of course there can be coding issues that can cause problems as well.

Drek-Rant (Non essential read): Thanks much for your time and work over the years Drek, it's greatly appreciated. Now that Paulius isn't a big time icon in the HLDS world anymore, you're the last we've got. I started trying to learn how to make a server back in early 2004 when I was only about 10-11 years old, still talked in leet speak on forums (even got criticized by you for being too noob, hehe) and had little knowledge (forum account was Fatal1ty87, lost info now). You were one of the main people who got me on the course for running a working server, along with Paulius. Now I'm almost 17 and posting on your new thread, which I'm surprised you've made, now that it's so many years later and HLDS is dying.

I've been wondering for a while, why do we decrease only the maxupdaterate if we experience lag, rather than both the maxrate/maxupdaterate?

Also, sv_minrate 0 has been recommended by you/paulius for years, I'd be interested in hearing a more specific reason for the 4 minrate and if 0 is still better performance wise (excluding security)

Before I get into this, I made a small change to the formula for sv_maxrate and corrected a couple of errors and typos, based on my answer to this post.

First off, I considered posting this in the SRCDS Windows forum, but so much still applies to HLDS, that I made the decision to post it here. In the same way that Valve continues to call it's dedicated server mailing lists the HLDS (Windows/Linux) lists, I suppose. The basic ideas apply to SRCDS as much as they do to HLDS, but some of the actual numbers will be different because the Source, Orangebox and L4D engines require more bandwidth than HLDS.

Also the Source, Orangebox and L4D engines are becoming increasingly more unfriendly to those running servers on limited bandwidth. Perhaps when 10mbps+ upload rates become the norm for broadband service in my part of the world (which will probably be sooner rather than later), I will post a thread in the SRCDS forum.

The sv_maxrate variable is pretty static. It is simply a number that takes your available bandwidth and divides it up between your clients. Unless your bandwidth is increased, there is no reason to change it. It also doesn't really matter all that much if you don't get it precisely correct, although you might want to consider leaving a little head room (ie. setting it slightly lower than the maximum you could potentially set it at).

However, the sv_maxupdaterate variable is very dependent on the game you are running, and the mods you are running on that game, as all these things have the potential to change the size of the packets being sent, and really getting it right is what will determine how smoothly your server runs. It is also much more of an art than it is a science, and the only way to get it exactly right is to adjust it with a full, active server.

There was a mistake in my post, and a typo or two, sv_minrate should always be set to 0, there is no reason to set it to anything else. As for sv_minupdaterate, I used to recommend sv_minupdaterate 0, but there are players that are using extremely low update rate settings to make them appear to move abnormally, and therefore make them harder to hit. Setting sv_minupdaterate to 4 should prevent this, while still allowing dialup users to set their rates as low as they need to maintain a reasonable quality game play experience.

So I have a 1.5Mbps connection, have normally been running a 12 slot server with AMXX and a few plugins.

sv_maxrate 14000
sv_maxupdaterate 52

Today I tried upping the maxupdaterate, and I got to the point where it was so high, that I tried uncapping it at 0 (and then maxrate at 0), and it still worked fine with no lag spikes.

I'm running Booster 2.40 as well with this config as I've found it best for my server:

booster_show_connmsg 0
booster_autofps 200
booster_minsleepms 3
booster_force_systicrate 0
booster_cpu_enabled 0 (I have the rest of CPU cvars in cfg, took them out in post to shorten)
booster_lite_mode 3

Does this seem strange for it to be working flawless at uncapped rates?

So I have a 1.5Mbps connection, have normally been running a 12 slot server with AMXX and a few plugins.

sv_maxrate 14000
sv_maxupdaterate 52

Today I tried upping the maxupdaterate, and I got to the point where it was so high, that I tried uncapping it at 0 (and then maxrate at 0), and it still worked fine with no lag spikes.

Was this with a full server? If it was, then there could be a fairly simple explanation. I think the default update rate for the Half-Life client is 20, so if you can set your max update rate higher than that, you probably won't notice any problems unless you get a bunch of hard core gamers connecting to your server that have all set their update rates very high.

The only way to test when you are able to set your rates that high is to get a bunch of friends to connect to your server, all with cl_updaterate set to something very high, such as 100.

Ah that makes sense. Thanks for your response. Yes it was a full server, was full for the longest time I'd ever seen before, so it was a great opportunity I thought. Later that day I asked if there were any server-wide lag spikes and they said a few, so it did seem to start lag spiking eventually with certain players / possibly people using mics with voicequal on 5, etc.

Thanks for that, I've linked them in the top post again. If you wouldn't mind I'd appreciate it if you incorporated the changes I made, the major one being that I recommend leaving 5% of your bandwidth in headroom.

Thanks for the tutorial Drek. It's really neat and helpful! I'm having a little trouble though - mainly in regards to bandwidth. I have a 25mbs/25mbs connection and I don't know if the rates can even be set this high.

I got these from a website someone linked in another thread I believe - all I had to do was just input my processor speed, RAM, and internet stats. So my question is, does this make sense/is it even possible for the rates to be that high?

Also, my server only gets 64 fps, I added (fps_max 600) in the config but it doesn't seem to really do anything.

You are so far over the maximums you would need to skydive to reach them. Welcome to the new generation of cable connections. You can use CAL config for your rates if you like. Your only potential limitation is your hardware - specifically your server box and your router.

If you are using a retail home router that might well be the bottleneck for you - not in terms of bandwidth, but in terms of your router's processor and the intensity of traffic it can handle. I can't really help you with that though, that will be a matter of trial and error for you.

Looking at the current incarnation of the CPL website I'm not sure that there is a current CAL config available. I believe the rates for CS were as follows:

sv_maxrate 25000
sv_maxupdaterate 101

I think those are the maximums for HLDS (although the max for the update rate might be 100, not sure about that).

I'm looking into a formula that can take in the CPU and RAM and generate an answer rather than some step limits. I would also like it to go higher than 32 players if the hardware is very good, to demonstrate multiple servers could be run off the hardware given. Perhaps I should include an input for dual/tripple/quad/oct core systems too. Also, I'd take the player value and knock off 25% if the person is using SRCDS.

Here is currently how the script works out how many players can be handled:

Also if we'd be taking multiple processors/cores into account, then RAM will need to be handled after. We can't simply multiply the players recommended by 2 as we'd end up with too little RAM to handle what the script tells us.

I would much appreciate your any input you have on this matter, or any other input you have towards the calculator in general

It's hard for me to offer anything concrete, other than to tell you what my experience has been. I have run a 17 slot hlds on an Athlon 1200 running Windows XP Pro, and Debian GNU/Linux. It ran very well and I ran a heavily modded 17 slot Natural Selection server on the same box, with bots, and it also ran quite well, although not perfectly.

I have run a 16 slot srcds and OrangeBox engine DOD:S server on an Athlon XP 1700+. It also ran very well, the box was running Debian GNU/Linux. However, on that same Athlon XP 1700+ I couldn't get a 16 slot Age of Chivalry server to run well. I have since switched to an Athlon 64 X2 3800+, also running Debian GNU/Linux, and a 12 slot Age of Chivalry server is running very well on it.

So far Age of Chivalry is the most demanding srcds/OrangeBox mod I have found, and Natural Selection is the most demanding hlds mod. A 32 slot Natural Selection server runs flawlessly on that same Athlon 64 X2 3800+ (only 12 slots though are human players, the rest are bots).

I know second hand that mods like Counter-Strike 1.6 will run on very old hardware. I know that back in the day they were running servers on Pentium 3 600's running Windows, and even older and slower hardware than that, although I don't know how many slots.

While I have seen the Extended Thread, I find it fascinating that people still would like to host servers from home.

Unfortunately in Australia, Internet Traffic is expensive which is prohibitely expensive also there's been debates about the upgrade of Fibre Optics through the National Broadband Network of Australia.

The server calculator is great, but that will only work if you meet the requirements of the Hardware Machine you're intending to host.

These days Dual-Core Processors are Cheap, so there's no reason why not to buy one, but Quad-Core or better would be more ideal and in some cases better than using an Intel Xeon Itanium or AMD's Opteron processor for a more cost-effective solution.

In terms of rates, like you've mentioned we go based on the upload rate (the theoretical side of how much upload speed you'll get per sec.)

But I guess it's mainly for the people with the low end machines who can't afford to buy PC's these days, and the target audience.