sgossard34

well it looks like you copied this guide from a very old source. alot of the numbers are far too conservative and out of date as well as the definitions. for optimum performance set the cl_cmdrate and cl_updaterate to 101 and 100 respectively. the cl_cmdrate should match your average fps exactly, not a division of. your rate values are off as well. you should set this value depending on what the server is running and how much bandwidth you can handle. i personally use 25000 rate and 20000 cl_rate. rate was not mentioned but is also a very important command. cl_rate and rate ARE NOT the same command. one controls upload amount and the other controls download. cl_rate is the upload one if i remember correctly. server side the sv_maxrate is default to 20000, not 99999. also using minrate is a very good idea. helps hte people who dont know these settings stay within a solid range. i like that you did this but your stuff is way to far out of date. here is a far better guide. mainly server side but will explaing alot and is current. ********* INTRODUCTION This is not a rant, correction or otherwise, just clarification of a few omissions and minor ones at that. The original article is very well written and intrinsically accurate. I consider this a technical enhancement to McClanes original article with a few additions. McClane's original article does overlook (probably intentionally) three things though in my opinion: 1) The affect of server side fps on high cl_updaterate values 2) Server side restriction of the cl_updaterate via sv_maxupdaterate 3) Cl_cmdrate inaccuracies due to server side fps. Although both server side fps and sv_maxupdaterate affect the accuracy of cl_updaterate, these can only be affected by the server admin. Again although server side fps affects the accuracy of cl_cmdrate usage, players are again powerless. Therefore the information below is (mostly) for clarification purposes only and of no real use to players except to pester server admins I do provide an alternate (not better or worse) method of tuning your rates for smooth play on individual servers. 1) CL_UPDATERATE This is a "request" value and often not the "actual" number of updates received by the client from the server. The actual number is capped by the server side frames per second (fps). This is due to an update only being available for each frame the server generates. I won't got into why this is the case but it was confirmed by a Valve software engineer a long time ago. Server side fps fluctuates rapidly depending on many factors which include, number of players on server, map complexity, host cpu cycles available and a multitude of server and client vars. The server admin has by far the largest level of control over the effective server side fps with several configuration options available which directly affect it. The sad news is that most default server setups and config files (host os and cs software) do not include the most useful ones (or poor defaults) leading most servers to run at sub 100fps levels off the shelf so to speak. Another reason why servers are not configured to run in excess of this is cpu cycles, more fps = higher cpu usage. Trade offs are therefore often made even by experienced server admins. So how does this affect players? Well, average servers run between 20 and 60 fps and as previously explained can only provide that many updates per second. This leads to inaccurate reports of choke level in certain scenarios. How? Well, during normal play with a cl_updaterate setting of 100 you may not be receiving that many updates, leading you to believe you are handling 100 updates per second fine. To ensure you are handling that many updates you would need to be playing on a server you KNOW is generating more than 100fps server side. Players cannot query the server side fps but it can be obtained via rcon using "rcon stats". Most good broadband connections can handle this level though (info from my own clan and customers). Slower speed connections (ISDN / Modem) certainly can't though. Steam 1.6 servers do seem to send noticeable more information is updates compared to 1.3 figures. From my own personal experience as a 64Kbits ISDN user I can verify that a reduction from 42-45 max to 32-35 max is needed between the 2 versions to prevent choke. This also affects adsl users and can lead to choke on servers running higher fps if they use high cl_updaterate values. I won't go into the maths as McClane's article does this amicably and can be adjusted to suit. Also, my own method (later in this missive) is an alternative to the maths approach. 2) SV_MAXUPDATERATE This is a bit simpler to explain at least. This caps the number of updates sent to the client regardless of what the cl_updaterate of the client is set to. The primary usage of this setting is to allow server admins to prevent flooding of the host servers connections (can happen on hardware running large numbers of ports on a 10mbit connection for example). It is more often used to clear up choke due to server side restriction of maxrate. As with above, the bad news is that by default this value is set to 60 (or in some cases undefined and defaults to 60). Again, although this setting can be reported via rcon using "rcon sv_maxupdaterate" (note without a subsequent value being set), it cannot be seen by a standard client/player. 3) CL_CMDRATE This is the number of updates clients send to the server and can contribute to choke as stated in McClane's article. However, due to server side fps all of those updates may not be used. If you are sending 100 updates a second and the server is only generating 50fps obviously some of your updates are not being fully used. As the hlds code is closed source I cannot document how the excess updates are handled but it's reasonable to assume they are used to some degree. Saying this it is best to send as many updates as possible. This gives the server a larger data sample to select the most accurate updates from. NOTES ON SV_MAXRATE I've deliberately not touched on restriction of the "rate" client side var using the server var "sv_maxrate". This is because sv_maxrate is reported by hlsw/gamespy/ase and the likes. Needless to say most clanservers and publics don't run at 25000 which does negate some of McClane's comments to a degree. His principles however is sound and can be used to work out accurate rates (cmdrate/updaterate) for servers running lower maxrates (eg. 10000 which is common). The main thing to note about this is at lower server maxrates, client rates have to be reduced accordingly to account for the lower bandwidth available for transmission and reception of updates. CORRECTING A MISCONCEPTION Choke is caused by crap servers? ABSOLUTE RUBBISH. Bear in mind what choke is, to quote McClane "the number of updates not sent in either direction because the communication link is saturated". Basically it's nearly always a combination of your client settings and your connection. NOTES ON SERVERS AND CHOKE / LOSS It is true however that extremely bad server configuration can cause choke by restriction of your client side settings. This is however very rare. I'm confident in saying that if the server is hosted by a reputable provider you will not see either of the 2 main reasons (see below). 1) Using a low sv_maxrate (usually to reduce bandwidth usage) but still using a high sv_maxupdaterate. Usually a sign of EXTREME inexperience and cost cutting combined. 2) Poor server connection compared to load eg. a high number of ports (and therefore players) on a connection not capable of handling them. This scenario is easier to spot as packet loss is usually seen as well as choke. There is a third server setup scenario you should watch for which is a little harder to spot. I won't name names but many of you will be aware of a few clanport providers who run ports with quite low sv_maxrate's (sometimes as low as 6000). These ports often show no loss and in most cases very little or no choke. Experienced admins are more than capable of configuring such servers and usually do so as an extreme cost cutting exercise. A low sv_maxrate combined with a low sv_maxupdate rate is used to cut bandwidth costs dramatically. Spotting the low sv_maxrate is easily done in hlsw etc. lower than 10000 - avoid them. Ramping up your cl_cmdrate will cause choke on these servers as this cannot be restricted server side. Secondly bullet reg and general in game accuracy are greatly reduced. QUICK GUIDE TO OPTIMISING RATES WITHOUT THE MATHS Knowing and understanding the above does allow us to more rapidly tune our rates on the fly according to the server we are playing on. In a perfect world we would be able to find out all of the servers rates and settings and work out the optimal client side rates for our own connections before even joining the server. However, a simple bit of on the fly trial and error can be much faster. As most players are broadband users, details below only apply to that connection type. 1) Use net_graph 3 to view your choke level. Make sure to pay attention during heavy fire fights when large numbers of players are still alive as these are the heaviest info moments (bullets flying everywhere, a player movement, deaths, weapon drops etc.) The first 1-2 seconds after spawn are also heavy info moments so watch then closely too. 2) For broadband users I recommend using 25000 rate (unless using external comms when 20000 is more appropriate). If my notes serve me accurately 25000 is a hard coded max rate of steam hlds servers so even though you can set higher it has no effect. If the server has a lower maxrate you need not worry, it will abide by it's setting and you need not change yours. 3) Start with cl_cmdrate and cl_updaterate at 100. Watch for choke, if 0 then play on, no changes are needed. This happens either if your conn can handle the 100 updates per sec or server side restrictions (as described above) have limited updates to a level your conn can handle. In either case you need make no changes. 4) If choke is seen, lower both cl_cmdrate and cl_updaterate equally by increments of 5 until choke returns to 0 during both situations outline in point 1. I then recommend lower both an additional 3 to account for heavier fire fights or moments busier than those you noted your choke level from. This method can be used on each server and ensures you as the client are providing and receiving as many updates as possible to/from the server without losing any. This leads to more accurate and responsive game play. Remember, server configurations differ wildly so it's best to do this EVERY TIME you join a different server. I personally have a set of aliases bound to 2 keys which allow me to increase or decrease such settings very quickly in game. Not essential but useful at times (see below). ADVANCED NOTES/TIPS The following notes are primarily for ISDN or slower connection users. They may be of limited or no use to other users. There are a couple of situations in game when adjusting your cmdrate and updaterate on the fly can aid responsiveness. To be of any use however you do need to know the servers sv_maxupdaterate and be sure it's running at more frames per second than that value. Both of these tweaks should be used with care as they can induce massive choke if set poorly. It's all trial and error so keep a VERY close eye on your net_graph 3 choke level. It is also very hard to perform these tips successfully without having a good knowledge of writing aliases which are then bound to keys. I personally have 4 keys in a cluster on my keyboard bound to aliases which when pressed either increase or decrease my cl_cmdrate or cl_updaterate by increments of 3 on the fly. DO NOT BOTHER ASKING FOR MY SCRIPT TO DO THIS. If you are not proficient enough to code it yourself stop reading here. TIP 1 This first tip is theoretical as I've not been able to prove it myself. But I have had reports from friends and colleagues with faster connections and keener eyes that it can work. As we know sv_maxupdaterate caps the clients cl_updaterate. We also know that there is no server side option to cap the clients cl_cmdrate. Well, on servers running as a high fps you can increase your cl_cmdrate individually and as high as your connection will permit before choking. I am told this can increase the accurate of bullet reg. This tweak is most useful when the servers sv_maxupdaterate is lower than your connection can handle giving you spare capacity (eg. servers running default 60). TIP 2 This second tip is only useful if on a specific server you can choke your connection and have to use lower cmdrate and/or updaterate to prevent choke in heavy fire fights etc. The easiest way for me to describe this is by way of example. I know that in heavy fire fights on ISDN I need to use cmdrate and updaterate of around 32-35 to prevent choke. But in situations when a lot less is going on I know I can get away with much higher settings See where I'm going here? Well, consider a 5v5 match - 10 lots of player info are being sent to all clients but as each player dies the amount of information required for each update reduces. So, using a little care and experience I gradually increase my cmdrate and updaterate on the fly as players die (checking for choke regularly). This increases the accuracy and responsiveness of my game play bit by bit. Should I be left in a last standing 1v1 standing scenario my cmdrate and updaterate can be as high as a broadband user on certain maps. TIP NOTES: The above tips are NOT cheats. At the end of the day I am merely leveling the playing field a little due to only having an ISDN connection. Remember that ADSL users will probably be using the settings I end up at all the time whereas I only achieve them during 1v1 battles on the simpler maps. Also, I'm a bit crap and need every "edge" I can get === Content publication granted by the original author, TAA|Vapor on behalf of TAA|Gaming - Original article available at http://www.taa-gaming.com/servers/advanced.php

no the audio part where i told everyone in TAC to get a knife and kill you all. then i chased after repo swearing and laughing at him and stuck my knife up his ass then yelled some more **** at him. it will make a nice addition to the clip for my my movie

sure i did. atma is just making an FA movie of me and i need someone elses demo to have my voice during a very special part with reprobait

i am making a movie including footage fro the tac vs pop FAL playoff match. i need the first round demo if anyone has it. could you please email me sgossard@ptdprolog.net or post back here if you still have it. i will give you access to my ftp so you can upload it. its very critical to the movie being made. thanks in advance.

i already have a post in our private forums relating to this idiot. he will be removed soon.

shotty you may be british but i still love you

shotty you may be british but i still love you

yes i know that site well. they often are influenced by their own sponsors and kick backs to promote certain products. most websites do this. thats why if you ask people in the know in the industry they will tell you not to take 99% of the tests and benchmarking done on the net with a grain of salt. also so many people rig the applications used to do this testing. even game demo testing is adjusted to certain hardware and results. tom's is nice for general info and reviews. but for detailed benchmarking and information i dont give it a second look.

yes i know that site well. they often are influenced by their own sponsors and kick backs to promote certain products. most websites do this. thats why if you ask people in the know in the industry they will tell you not to take 99% of the tests and benchmarking done on the net with a grain of salt. also so many people rig the applications used to do this testing. even game demo testing is adjusted to certain hardware and results. tom's is nice for general info and reviews. but for detailed benchmarking and information i dont give it a second look.

make sure and take your own advice shotty :)does anyone know the site that does these guides on a regular basis? i know some site does it. i just cannot remember the name. might be nice to link that in here as well. i would love to do an intel guide but i honestly dont have the time. anyone else willing to do so?

make sure and take your own advice shotty :)does anyone know the site that does these guides on a regular basis? i know some site does it. i just cannot remember the name. might be nice to link that in here as well. i would love to do an intel guide but i honestly dont have the time. anyone else willing to do so?

it does alot more than just that. if anyone asked me for a PC i would recommend intel everytime, business or personal. i want a CPU that is solid across the board. not one that might compete on a few levels. and your prices are off. you can get a p4 3.4 EE for $900 i think we need alot more details and or benchmarks/tests to decide. one little graph from a source unknown wont do.

it does alot more than just that. if anyone asked me for a PC i would recommend intel everytime, business or personal. i want a CPU that is solid across the board. not one that might compete on a few levels. and your prices are off. you can get a p4 3.4 EE for $900 i think we need alot more details and or benchmarks/tests to decide. one little graph from a source unknown wont do.

i really liked the bright blue text gator. leave it

i really liked the bright blue text gator. leave it

they do work in 32 bit apps. hence why the game was able to be played on the CPU.

they do work in 32 bit apps. hence why the game was able to be played on the CPU.

actually i have done my research. if you would realize that you dont compare 64 bit cpu's in a 32 bit comparison. even if you are running the CPU in 32 bit mode. let me put in some itanium benchmarks in as well :roll: anymore colorful pictures?

actually i have done my research. if you would realize that you dont compare 64 bit cpu's in a 32 bit comparison. even if you are running the CPU in 32 bit mode. let me put in some itanium benchmarks in as well :roll: anymore colorful pictures?

well i dont drink so that might be a problem. i will have mac make a video though....macfamastraining.avii would smoke with mac but i have a funny feeling he does not smoke the green with his kids around.

well i dont drink so that might be a problem. i will have mac make a video though....macfamastraining.avii would smoke with mac but i have a funny feeling he does not smoke the green with his kids around.

ya i did most of the gameplay designs for 2.7-3.0:)love me

ya i did most of the gameplay designs for 2.7-3.0:)love me

he will after he upgrades his stupid ME machines :twisted: :shock: :? 8) :x :evil: :twisted: :roll: :wink: :!: :?: :idea: i like the little faces

he will after he upgrades his stupid ME machines :twisted: :shock: :? 8) :x :evil: :twisted: :roll: :wink: :!: :?: :idea: i like the little faces