I use to run Linux and now Im running Windows and they are both shite. I cancelled with Gameservers and moved to Nuclear Fallout but can't say im quite pleased.rnrnI think it also has to do with on what kind of machine you are on. High performance servers, claimed by Nuclear Fallout, run better on Windows then on Linux, and the other way around, basic servers run better on Linux then on Windows.rnrnAnd with your setup you have to pay attention, lets say you have a plugin which affects your ammo ??pdata?? that there might be an addition in the plugin to function for Linux, don't know how that will affect when placed on a Windows server.

I have both Linux and windows, rent two from gameservers and two windows running on a machine at my home. All but 1 are loaded down with plugins, and to me there are virtually no differences. I think the hardware, location, and possibly the cpu and memory allocated could make a difference. Some hosts try and run too many servers on a box.

And with your setup you have to pay attention, lets say you have a plugin which affects your ammo ??pdata?? that there might be an addition in the plugin to function for Linux, don't know how that will affect when placed on a Windows server.

Interesting. My test server I use is setup to dual boot XP Pro and Ubuntu Linux. The HLDS on the Linux install is definitely faster. As for Windows servers, I have noticed that they generally have bad registration unless you have a lower latency. Could be incorrect setup though. I know Valve has some magic fix with opening Windows Media player for a high resolution timer. LOLnnBTW, Many game server hosting companies have shared hosting which means there can be multiple game servers running on the same box with virtualization or running in the same environment etc.. This is OK if they don't over sell the servers CPU time or bandwidth. Shared servers can also suffer (all hosted game servers on that box) if one is causing problems such as expensive plugins, mods or incorrectly set up. Generally a good host will disable an offending game server when this happens but not always the case. As for performance, one of the best things you can try is to see how high you can set your tick rate to. This setting is sys_ticrate and it goes into your server.cfg. It is basically how many times HLDS will complete a full program loop per second. The FPS also relates to an increase over the base ping a player has. An FPS of 100 will add approximately 10ms. You can see what your currently running by using rcon stats in console. This tells you your CPU usage as well. What you want to do is increase this to the point where your CPU usage is below about 50%. I should also point out that these numbers will fluctuate. FPS and CPU usage won't always be at a set amount so use rcon stats several times in a row to get a good idea. Also, make sure to check the terms from your host to see if changing the sys_ticrate is allowed. Some don't let you set this and can get your server disabled!nnAfter adjusting your sys_ticrate, now start playing with server defined rates and find the best settings that work for what you have. You might not be able to get a server with 32 players and be able to have a max rate of 25k and updaterate 75 or higher because the connection is over saturated. CPU time available and how high you can get your FPS will also affect how high you can go. It's all a matter of testing and finding what works.nnI've had three DoD servers hosted by GameServers (LA, Chicago and Dallas) and the best combination I have found for them seems to be right around the following:nsys_ticrate 300nsv_maxrate 20000 nsv_minrate 10000nsv_maxupdaterate 101nsv_minupdaterate 40nnThere wasn't too much different between them and the above is what I'm running on the current server in Dallas.nnYou can also read what Steam offers on the subject at:nhttps://support.steampowered.com/kb_article.php?ref=5386-HMJI-5162nSome of which can't be done because of no physical access to the server.nnIf you have problems with shot registration, it could just be a matter of not having your own rates set correctly along with the server. Everyone's connection is different and what rates someone else uses on the net might not work in your case. To make things worse, these can easily change from server to server. Generally you want your rates as high as they will go to prevent missed shots/interpolation or in short, interp. Interp is where the game will guess where the player your shooting at is by guessing off of the last packet received from them. The less data you receive (cl_updaterate) the more interp will have to take place. As you can guess, a player may actually be in a different location on your end as to what the server sees. Ideally you want to set your rates so you see what the server sees as close as possible. The higher your cl_updaterate, the more you can decrease your interp which is ex_interp in the console. Setting this to 0 will automatically adjust it for your current cl_updaterate. The less interp you have though the more players can appear to jerk around. This is because you are seeing their position based on their packets and they are where the server sees them. Now with cl_cmdrate, this is the amount of data your sending to the server when you run and shoot. You want this high enough that everything is getting through but not so high that your connection or the server can't handle it. How high these settings can go depend on your connection and the server and it's connection. It can all be very confusing if you have never messed with your rates, a quick and easy way is to go into your console and type: net_graph to 1nnThis will bring up the net graph with a graph. The top line represents ping. You should have a completely green, mostly flat line of dots. If not, your connection is over saturated (other people sharing the connection, torrents, etc), your dropping packets, or the data is getting dropped somewhere on it's way to the server, you'll see red or yellow depending on the problem. This is bad and you should check out your connection to find what is causing the problem before proceeding.nnNow, look at the bottom part of the graph. You want see bluish-to purple dots down there. If you are seeing red, up your cl_cmdrate to the point that they are gone. Test this in a firefight as well. It should be set to where you have no more red dots at the bottom or as few as possible. Contrary to popular belief, cl_cmdrate does go above 101, cl_updaterate used to but is now maxed at 102 since the latest barrage of updates from Steam. Easy enough. If you have yellowish/orange dots, lower your cl_updaterate. If lower than the previous setting, interp will automatically adjust but if increasing from a previous amount, be sure to use ex_interp 0. If you can't get satisfactory results, changing your base rate can help. Most importantly though is playing on servers where you can have the least amount of interp. I have read things to the effect that your cl_updaterate should match the server's sv_maxupdaterate but this is bad advice unless the server and it's connection can actually handle that amount all the way up to full capacity and very few servers are fine tuned for this. Your connection must also be able to handle it too! ;)nnPersonally I run cl_updaterate 91, cl_cmdrate 120, rate 20k and an ex_interp of 0.013. If the server I'm playing on can't handle these rates, I will make some minor exceptions and if unacceptable, move on to a different server that is/can actually handle it's player load.nnAnother thing, setting rates manually for every server you play on can be a pita but fortunately you can bind rates to keys in your config.cfg or userconfig.cfg etc..nn@tank - That is unfortunate that Nuclear Fallout isn't keeping up with their reputation. They are supposed to be one of the best.nn@diamond - I was under the impression that the Linux difference has a default -5 value and is added when needed as it supposedly checks for Linux automatically with pdata commands. That is good to know. :) So far I haven't had an issue *yet*.

@diamond - I was under the impression that the Linux difference has a default -5 value and is added when needed as it supposedly checks for Linux automatically with pdata commands. That is good to know. :) So far I haven't had an issue *yet*.

Yeah, your graph looks good. Choke is basically too much data is being sent/requested. Usually, it's the server not being able to send out enough data as requested by the client in which case you would lower cl_updaterate. If the choke appears in a firefight, lower your cl_cmdrate. As for sv_maxupdaterate, yes, that will limit people from using a higher cl_updaterate. They can set it higher but they wont be able to receive more packets then the server sends them.nnOn your server, that looks normal for the amount of players. As long as your not spiking 100% CPU usage when full, it will be OK. If it does, lower the tick rate. As for the Linux server, it could have been just a bad copy/version of Linux, faulty hardware, bad connection or a plugin/mod that was causing problems.

do not forget that hl1/hl2-engine has binary for different cpu-types. so an check between linux/windows can only be real if you use the same machine(cpu)-type.rnexample: some bugs of engine are in binary for an cputyp like i486 that are not in i686 ..

you need to be renting a server from me at www.rtgservers.com

Any body using these?rnsv_unlag 1rnsv_maxunlag .2