玩樂天堂 pockyland

標題: Tickrate [打印本頁]
作者: maska    時間: 2009-3-23 18:57
標題: Tickrate
Tickrate                      From Whisper's Wiki                                                            
Contents [hide]

Definitions tickrate From Valve:During each tick, the server processes incoming user commands, runs aphysical simulation step, checks the game rules, and updates all objectstates. After simulating a tick, the server decides if any client needsa world update and takes a snapshot of the current world state ifnecessary. A higher tickrate increases the simulation precision, butalso requires more CPU power and available bandwidth on both server andclient.When a client connects to a server, the clients Source Enginematches the SRCDS (Source Dedicated Server) tickrate that the clientconnected to.
THE ONLY PLACE YOU CAN CHANGE THE TICKRATE IS VIA THE COMMAND STARTUP LINE.
NO, THERE IS NO WHERE ELSE, GOT IT?
SRCDS Source Dedicated Server. The program you should be running and trying to optimise if you are here.FPS Frames per Second.Client FPS Is the number of times per second the gamechecks for inputs, either from keyboard/mouse and incoming gamepackets, basically any I/O operation.Server FPS Because there are no keyboard or mouse I/O's occurring, it only deals with how often the server checks for game packets.fps_max Sets an upper limit on the frames per second the server runs at. Default=300sv_maxrate The Maximum amount of data in Bytes perSecond the server will send to the client. Conversely, the Maximumamount of data in Bytes per Second the Client can request from theServer. sv_maxrate overrides the clients rate setting if sv_maxrate isless than the clients rate setting. Default=0 Maximum=30000sv_minrate The Minimum amount of data in Bytes perSecond the server will send to the client. Conversely, the Minimumamount of data in Bytes per Second the Client can request from theServer. sv_minrate overrides the clients rate setting if sv_minrate isgreater than the clients rate setting. Default=0sv_maxupdaterate The Maximum amount of Update perSecond the server will send to the client. Conversely, the Maximumamount of Updates per Second the Client can request from the Server.sv_maxupdaterate overrides the clients cl_updaterate setting ifsv_maxupdaterate is less than the clients cl_updaterate setting. Default=60sv_minupdaterate The Minimum amount of Update perSecond the server will send to the client. Conversely, the Minimumamount of Updates per Second the Client can request from the Server.sv_minupdaterate overrides the clients cl_updaterate setting ifsv_minupdaterate is greater than the clients cl_updaterate setting. Default=0rate The Maximum amount of Bytes Per Second the Clientwill request from the server. rate overrides the servers sv_maxratesetting if rate is less than the servers sv_maxrate setting. Default=(Depends Upon Clients STEAM Internet Connection Setting) Maximum=30000cl_updaterate The Maximum amount of Updates Per Secondthe Client will request from the server. cl_updaterate overrides theservers sv_maxupdaterate setting if cl_updaterate is less than theservers sv_maxupdaterate setting. Default=20cl_cmdrate The Maximum amount of Updates Per Second the Client will Send to the server. Default=30 Minimum=10 Maximum=100NB: sv_maxupdaterate and cl_updaterate cannot cause more data to besent to the client than the sv_maxrate and rate settings allow, or theservers, or most likely the clients actual available bandwidth allows.Choke occurs when either;
The servers sv_maxupdaterate causes the amount of bandwidth toexceed the bandwidth allocated per client by sv_maxrate or the totalamount of bandwidth the server has access to,
Or
The clients cl_updaterate causes the amount of bandwidthrequired by the client to exceed the clients rate setting or the totalamount of bandwith the client has access to.
More Info here: Valve's Source Multiplayer Networking Explanation
Instructions Linux Kernel Timer InstructionsThanks to triphammer in the STEAM Linux SRCDS Forum
You need to do a custom (re)compile of the linux kernel in order to change kernel interruptability / timer.

Since Kernel 2.6.14 you change the HZ with "make menuconfig",just go to: "Processor type and features" > "Timer frequency (XXXXXHZ)". The default HZ for 2.4 Kernels is 100.You can also change the HZ via the "USER_HZ" variable located in:include/asm-<arch>/param.h.
param.h:
define USER_HZ       100             /* .. some user interfaces are in "ticks" */

More along the lines of your question, you can also set the kernel timer frequency by chaning the HZ variable in the same file
define HZ            1000            /* Internal kernel timer frequency */
Also:
+       config HZ
+        int "Frequency of the Timer Interrupt (1000 or 100)"
+        range 100 1000
+        default 1000
+        help
+          Allows the configuration of the timer frequency. It is customary
+          to have the timer interrupt run at 1000 HZ but 100 HZ may be more
+          beneficial for servers and NUMA systems that do not need to have
+          a fast response for user interaction and that may experience bus
+          contention and cacheline bounces as a result of timer interrupts.
+          Note that the timer interrupt occurs on each processor in an SMP
+          environment leading to NR_CPUS * HZ number of timer interrupts
+          per second.
+
endmenu

For a server fps to cater for you high tickrate under Linux, youeither need to recompile your 2.4 Kernel, with its Kernel timerresolution changed, but the easiest and probably best course of actionis to use the 2.6 Kernel and change the "USER_HZ" variable, (I wouldsuggest starting at 500 and seeing what happens before experimentingwith other numbers) which will enable higher server fps on your Linuxserver.

Instructions for compiling the Linux kernel:
The following webpages provide instructions for compiling the Linux kernel:
Client Settings Clients must have their STEAM Internet Connection Settings setup correctly for their Internet connection. See here for explanation on how to do this.
The clients rate should = the servers sv_maxrate
The clients cl_updaterate should = the servers sv_maxupdaterate which equals the servers tickrate
Thus a server with sv_maxrate 20000 tickrate 100 sv_maupdaterate 100 the clients though run the following settings:
These settings will provide the best client experience so long asyour server & network can cope with running with a high tickrateand the rates required to take advantage of them.
NB: If your server settings are different to the examplejust mentioned, your client settings will have to change accordingly.This is just an example, do not think that these rates are optimum forall server settings, they are not, and your optimum client settingswill need to change accordingly.
Summary < 20 Player servers
-tickrate 100
sv_maxrate 30000
sv_maxupdaterate 100
fps_max 600

> 20 Player servers
-tickrate 66
sv_maxrate 20000
sv_maxupdaterate 66
fps_max 600

Make sure you have the CPU and bandwidth to cope
What you need to look out for is high CPU usage on the serverand/or choke on clients that did not get it before you made changes toyour servers tickrate and associated settings, and/or fps that runningconstantly well below the Kernel Timer and/or below the tickrate. Orotherwise, just blatanly obvious crap lag on the server to put itbluntly.
i.e. If you run at 66 tickrate with 50% CPU and 100 tickrate at90% CPU then its obvious that 66 tickrate is what you are going to haveto run your server at.
If you set your kernel timer to 500Hz or there abouts, andfps_max at 600, but your server is only getting 150-200 fps constantly,then its obvious you need to change the kernel timer and/ore thefps_max to a lower setting.
Server Bandwidth Calculation for Dummies sv_maxrate and rate are the 2 variables that decide the maximumamount of bandwidth each player will use. Both are measured in Bytesper Second, so an sv_maxrate of 20000 = 20,000 Bytes per Second! A Rateof 15000 = 15,000 Bytes per Second.
Network Speeds are by convention quoted on bits per second,whether Kilobits (Kb) 1,000 bits, Megabits (Mb) 1,000,000 bits orGigabits (Gb) 1,000,000,000 bits.
The other convention is b is for bit, B is for Byte, it is important not to confuse the two.
8 bits = 1 Byte
To calculate the amount of upload bandwidth your server musthave, you multiply your sv_maxrate by the number of players on theserver. Thus a sv_maxrate of 20000 with 20 players will require atleast 20 * 20,000 = 400,000 Bytes per Second of Bandwidth. I say atleast, because your theoretical maximum upload speed is just that,theoretical, and you will find that most connections will not sustaintheir theoretical maximums for long periods of time, which is exactlyhow GameServers must operate to provide a positive end user experience.
Now going back to our example, we have calculated that you aregoing to require 400,000 Bytes per Second of Bandwidth to serve 20players. We now need to convert this to normal Networking conventions,so we can compare apples with apples. To do this, the calculation forthis example is as follows:
400,000 Bytes * 8 bits / 1,000 = 3,200 KiloBits/Second (3,200Kbps) or 400,000 Bytes * 8 bits / 1,000,000 = 3.2 Megabits/Second (3.2Mbps)
The point of this calculation is that whatever Bytes Per Seconda particular SRCDS setup requires, you need to convert that into a bitspeed, by multiplying the total about of bytes generated per second by8 (8 bits = 1 Byte) and then convert that into either kilobits ormegabits, by dividing by 1,000 for kilo or 1,000,000 for mega to giveyou a value in Kilobits per Second (Kbps) or Megabits per Second(Mbps), whichever is easier to read so you are able to make a correctcomparison with your connection speed.
Please realise that your X Mbps connection maybe rated veryclose to what the server requires, but it is nearly always necessary toleave an overhead of between 10%-25% to make sure the server can alwayscope since many connections are not able to constantly run at theirpeak theorectical speeds. So an sv_maxrate 20000 server with 20 playersis probably going to require a 4Mbps Upstream Connection to adequatelycope with the load.
Final Calculation looks like this: sv_maxrate * {player number} * 8 / 1,000 = Maximum Upstream Speed in Kbps your server requires.
This calculation will work for multiple SRCDS processes on the one physical server.
If you want to turn this calculation around, and wish tocalculate the maximum theoretical sv_maxrate your server can run for agiven upload speed (in kbps) and player number, the calculation is asfollows:
upload bandwidth in kilobits per second  / 8 * 1000 / player number = the theoretical maximum sv_maxrate you can run your server at.
This Calculation only works for a single SRCDS process on a single physical server.
Hopefully now, you can all work out just how much UpstreamBandwidth your server requires for any given sv_maxrate, upstreambandwidth and player number values.
Below are tables that with calculation values already worked out for you.
Maximum theoretical required upload bandwidth in kilobits per second for a given player number & sv_maxrate
sv_maxrate --> 3,000 5,000 7,500 10,000 12,000 15,000 17,500 20,000 25,000 30,000
Total Players 6 144 Kbps  240 Kbps  360 Kbps 480 Kbps 576 Kbps 720 Kbps 840 Kbps 960 Kbps 1,200 Kbps 1,440 Kbps
Total Players 8 192 Kbps 320 Kbps 480 Kbps 640 Kbps 768 Kbps 960 Kbps 1,120 Kbps 1,280 Kbps 1,600 Kbps 1,920 Kbps
Total Players 10 240 Kbps 400 Kbps 600 Kbps 800 Kbps 960 Kbps 1,200 Kbps 1,400 Kbps 1,600 Kbps 2,000 Kbps 2,400 Kbps
Total Players 12 288 Kbps 480 Kbps 720 Kbps 960 Kbps 1,152 Kbps 1,440 Kbps 1,680 Kbps 1,920 Kbps 2,400 Kbps 2,880 Kbps
Total Players 14 336 Kbps 560 Kbps 840 Kbps 1,120 Kbps 1,344 Kbps 1,680 Kbps 1,960 Kbps 2,240 Kbps 2,800 Kbps 3,360 Kbps
Total Players 16 384 Kbps 640 Kbps 960 Kbps 1,280 Kbps 1,536 Kbps 1,920 Kbps 2,240 Kbps 2,560 Kbps 3,200 Kbps 3,840 Kbps
Total Players 18 432 Kbps 720 Kbps 1,080 Kbps 1,440 Kbps 1,728 Kbps 2,160 Kbps 2,520 Kbps 2,880 Kbps 3,600 Kbps 4,320 Kbps
Total Players 20 480 Kbps 800 Kbps 1,200 Kbps 1,600 Kbps 1,920 Kbps 2,400 Kbps 2,800 Kbps 3,200 Kbps 4,000 Kbps 4,800 Kbps
Total Players 22 528 Kbps 880 Kbps 1,320 Kbps 1,760 Kbps 2,112 Kbps 2,640 Kbps 3,080 Kbps 3,520 Kbps 4,400 Kbps 5,280 Kbps
Total Players 24 576 Kbps 960 Kbps 1,440 Kbps 1,920 Kbps 2,304 Kbps 2,880 Kbps 3,360 Kbps 3,840 Kbps 4,800 Kbps 5,760 Kbps
Total Players 28 672 Kbps 1,120 Kbps 1,680 Kbps 2,240 Kbps 2,688 Kbps 3,360 Kbps 3,920 Kbps 4,480 Kbps 5,600 Kbps 6,720 Kbps
Total Players 32 768 Kbps 1,280 Kbps 1,920 Kbps 2,560 Kbps 3,072 Kbps 3,840 Kbps 4,480 Kbps 5,120 Kbps 6,400 Kbps 7,680 Kbps
Total Players 36 864 Kbps 1,440 Kbps 2,160 Kbps 2,880 Kbps 3,456 Kbps 4,320 Kbps 5,040 Kbps 5,760 Kbps 7,200 Kbps 8,640 Kbps
Total Players 40 960 Kbps 1,600 Kbps 2,400 Kbps 3,200 Kbps 3,840 Kbps 4,800 Kbps 5,600 Kbps 6,400 Kbps 8,000 Kbps 9,600 Kbps
Total Players 44 1,056 Kbps 1,760 Kbps 2,640 Kbps 3,520 Kbps 4,224 Kbps 5,280 Kbps 6,160 Kbps 7,040 Kbps 8,800 Kbps 10,560 Kbps
Total Players 48 1,152 Kbps 1,920 Kbps 2,880 Kbps 3,840 Kbps 4,608 Kbps 5,760 Kbps 6,720 Kbps 7,680 Kbps 9,600 Kbps 11,520 Kbps
Total Players 56 1,344 Kbps 2,240 Kbps 3,360 Kbps 4,480 Kbps 5,376 Kbps 6,720 Kbps 7,840 Kbps 8,960 Kbps 11,200 Kbps 13,440 Kbps
Total Players 64 1,536 Kbps 2,560 Kbps 3,840 Kbps 5,120 Kbps 6,144 Kbps 7,680 Kbps 8,960 Kbps 10,240 Kbps 12,800 Kbps 15,360 Kbps
Total Players 72 1,728 Kbps 2,880 Kbps 4,320 Kbps 5,760 Kbps 6,912 Kbps 8,640 Kbps 10,080 Kbps 11,520 Kbps 14,400 Kbps 17,280 Kbps
Total Players 80 1,920 Kbps 3,200 Kbps 4,800 Kbps 6,400 Kbps 7,680 Kbps 9,600 Kbps 11,200 Kbps 12,800 Kbps 16,000 Kbps 19,200 Kbps
Total Players 88 2,112 Kbps 3,520 Kbps 5,280 Kbps 7,040 Kbps 8,448 Kbps 10,560 Kbps 12,320 Kbps 14,080 Kbps 17,600 Kbps 21,120 Kbps
Total Players 96 2,304 Kbps 3,840 Kbps 5,760 Kbps 7,680 Kbps 9,216 Kbps 11,520 Kbps 13,440 Kbps 15,360 Kbps 19,200 Kbps 23,040 Kbps
Total Players 100 2,400 Kbps 4,000 Kbps 6,000 Kbps 8,000 Kbps 9,600 Kbps 12,000 Kbps 14,000 Kbps 16,000 Kbps 20,000 Kbps 24,000 Kbps
Total Players 104 2,496 Kbps 4,160 Kbps 6,240 Kbps 8,320 Kbps 9,984 Kbps 12,480 Kbps 14,560 Kbps 16,640 Kbps 20,800 Kbps 24,960 Kbps
Total Players 110 2,640 Kbps 4,400 Kbps 6,600 Kbps 8,800 Kbps 10,560 Kbps 13,200 Kbps 15,400 Kbps 17,600 Kbps 22,000 Kbps 26,400 Kbps
Total Players 112 2,688 Kbps 4,480 Kbps 6,720 Kbps 8,960 Kbps 10,752 Kbps 13,440 Kbps 15,680 Kbps 17,920 Kbps 22,400 Kbps 26,880 Kbps
Total Players 128 3,072 Kbps 5,120 Kbps 7,680 Kbps 10,240 Kbps 12,288 Kbps 15,360 Kbps 17,920 Kbps 20,480 Kbps 25,600 Kbps 30,720 Kbps
Calculation for theoretical total kilobits per second speed = (sv_maxrate * player number * 8 / 1,000)

Maximum theoretical required upload bandwidth in megabits per second for a given player number & sv_maxrate
sv_maxrate --> 3,000 5,000 7,500 10,000 12,000 15,000 17,500 20,000 25,000 30,000
Total Players 6 0.144 Mbps 0.240 Mbps 0.360 Mbps 0.480 Mbps 0.576 Mbps 0.720 Mbps 0.840 Mbps 0.960 Mbps 1.200 Mbps 1.440 Mbps
Total Players 8 0.192 Mbps 0.320 Mbps 0.480 Mbps 0.640 Mbps 0.768 Mbps 0.960 Mbps 1.120 Mbps 1.280 Mbps 1.600 Mbps 1.920 Mbps
Total Players 10 0.240 Mbps 0.40 Mbps 0.60 Mbps 0.80 Mbps 0.96 Mbps 1.20 Mbps 1.40 Mbps 1.60 Mbps 2.00 Mbps 2.40 Mbps
Total Players 12 0.288 Mbps 0.48 Mbps 0.72 Mbps 0.96 Mbps 1.15 Mbps 1.44 Mbps 1.68 Mbps 1.92 Mbps 2.40 Mbps 2.88 Mbps
Total Players 14 0.336 Mbps 0.56 Mbps 0.84 Mbps 1.12 Mbps 1.34 Mbps 1.68 Mbps 1.96 Mbps 2.24 Mbps 2.80 Mbps 3.36 Mbps
Total Players 16 0.384 Mbps 0.64 Mbps 0.96 Mbps 1.28 Mbps 1.54 Mbps 1.92 Mbps 2.24 Mbps 2.56 Mbps 3.20 Mbps 3.84 Mbps
Total Players 18 0.432 Mbps 0.72 Mbps 1.08 Mbps 1.44 Mbps 1.73 Mbps 2.16 Mbps 2.52 Mbps 2.88 Mbps 3.60 Mbps 4.32 Mbps
Total Players 20 0.480 Mbps 0.80 Mbps 1.20 Mbps 1.60 Mbps 1.92 Mbps 2.40 Mbps 2.80 Mbps 3.20 Mbps 4.00 Mbps 4.80 Mbps
Total Players 22 0.528 Mbps 0.88 Mbps 1.32 Mbps 1.76 Mbps 2.11 Mbps 2.64 Mbps 3.08 Mbps 3.52 Mbps 4.40 Mbps 5.28 Mbps
Total Players 24 0.576 Mbps 0.96 Mbps 1.44 Mbps 1.92 Mbps 2.30 Mbps 2.88 Mbps 3.36 Mbps 3.84 Mbps 4.80 Mbps 5.76 Mbps
Total Players 28 0.672 Mbps 1.12 Mbps 1.68 Mbps 2.24 Mbps 2.69 Mbps 3.36 Mbps 3.92 Mbps 4.48 Mbps 5.60 Mbps 6.72 Mbps
Total Players 32 0.768 Mbps 1.28 Mbps 1.92 Mbps 2.56 Mbps 3.07 Mbps 3.84 Mbps 4.48 Mbps 5.12 Mbps 6.40 Mbps 7.68 Mbps
Total Players 36 0.864 Mbps 1.44 Mbps 2.16 Mbps 2.88 Mbps 3.46 Mbps 4.32 Mbps 5.04 Mbps 5.76 Mbps 7.20 Mbps 8.64 Mbps
Total Players 40 0.960 Mbps 1.60 Mbps 2.40 Mbps 3.20 Mbps 3.84 Mbps 4.80 Mbps 5.60 Mbps 6.40 Mbps 8.00 Mbps 9.60 Mbps
Total Players 44 1.056 Mbps 1.76 Mbps 2.64 Mbps 3.52 Mbps 4.22 Mbps 5.28 Mbps 6.16 Mbps 7.04 Mbps 8.80 Mbps 10.56 Mbps
Total Players 48 1.152 Mbps 1.92 Mbps 2.88 Mbps 3.84 Mbps 4.61 Mbps 5.76 Mbps 6.72 Mbps 7.68 Mbps 9.60 Mbps 11.52 Mbps
Total Players 56 1.344 Mbps 2.24 Mbps 3.36 Mbps 4.48 Mbps 5.38 Mbps 6.72 Mbps 7.84 Mbps 8.96 Mbps 11.20 Mbps 13.44 Mbps
Total Players 64 1.536 Mbps 2.56 Mbps 3.84 Mbps 5.12 Mbps 6.14 Mbps 7.68 Mbps 8.96 Mbps 10.24 Mbps 12.80 Mbps 15.36 Mbps
Total Players 72 1.728 Mbps 2.88 Mbps 4.32 Mbps 5.76 Mbps 6.91 Mbps 8.64 Mbps 10.08 Mbps 11.52 Mbps 14.40 Mbps 17.28 Mbps
Total Players 80 1.920 Mbps 3.20 Mbps 4.80 Mbps 6.40 Mbps 7.68 Mbps 9.60 Mbps 11.20 Mbps 12.80 Mbps 16.00 Mbps 19.20 Mbps
Total Players 88 2.112 Mbps 3.52 Mbps 5.28 Mbps 7.04 Mbps 8.45 Mbps 10.56 Mbps 12.32 Mbps 14.08 Mbps 17.60 Mbps 21.12 Mbps
Total Players 96 2.304 Mbps 3.84 Mbps 5.76 Mbps 7.68 Mbps 9.22 Mbps 11.52 Mbps 13.44 Mbps 15.36 Mbps 19.20 Mbps 23.04 Mbps
Total Players 100 2.400 Mbps 4.00 Mbps 6.00 Mbps 8.00 Mbps 9.60 Mbps 12.00 Mbps 14.00 Mbps 16.00 Mbps 20.00 Mbps 24.00 Mbps
Total Players 104 2.496 Mbps 4.16 Mbps 6.24 Mbps 8.32 Mbps 9.98 Mbps 12.48 Mbps 14.56 Mbps 16.64 Mbps 20.80 Mbps 24.96 Mbps
Total Players 110 2.640 Mbps 4.40 Mbps 6.60 Mbps 8.80 Mbps 10.56 Mbps 13.20 Mbps 15.40 Mbps 17.60 Mbps 22.00 Mbps 26.40 Mbps
Total Players 112 2.688 Mbps 4.48 Mbps 6.72 Mbps 8.96 Mbps 10.75 Mbps 13.44 Mbps 15.68 Mbps 17.92 Mbps 22.40 Mbps 26.88 Mbps
Total Players 128 3.072 Mbps 5.12 Mbps 7.68 Mbps 10.24 Mbps 12.29 Mbps 15.36 Mbps 17.92 Mbps 20.48 Mbps 25.60 Mbps 30.72 Mbps
Calculation for theoretical total megabits per second speed = (sv_maxrate * player number * 8 / 1,000,000)

Maximum theoretical sv_maxrate value you can run for a given upload speed
Upload Bandwidth --> 128 kbps 256 kbps 384 kbps 512 kbps 768 kbps 1,024 kbps 1,544 kbps 2,048 kbps 5,000 kbps 10,000 kbps
Total Players 4 4,000 8,000 12,000 16,000 24,000 30,000 30,000 30,000 30,000 30,000
Total Players 6 2,667 5,333 8,000 10,667 16,000 21,333 30,000 30,000 30,000 30,000
Total Players 8 2,000 4,000 6,000 8,000 12,000 16,000 24,125 30,000 30,000 30,000
Total Players 10 1,600 3,200 4,800 6,400 9,600 12,800 19,300 25,600 30,000 30,000
Total Players 12 1,333 2,667 4,000 5,333 8,000 10,667 16,083 21,333 30,000 30,000
Total Players 14 1,143 2,286 3,429 4,571 6,857 9,143 13,786 18,286 30,000 30,000
Total Players 16 1,000 2,000 3,000 4,000 6,000 8,000 12,063 16,000 30,000 30,000
Total Players 18 889 1,778 2,667 3,556 5,333 7,111 10,722 14,222 30,000 30,000
Total Players 20 800 1,600 2,400 3,200 4,800 6,400 9,650 12,800 30,000 30,000
Total Players 22 727 1,455 2,182 2,909 4,364 5,818 8,773 11,636 28,409 30,000
Total Players 24 667 1,333 2,000 2,667 4,000 5,333 8,042 10,667 26,042 30,000
Total Players 26 615 1,231 1,846 2,462 3,692 4,923 7,423 9,846 24,038 30,000
Total Players 28 571 1,143 1,714 2,286 3,429 4,571 6,893 9,143 22,321 30,000
Total Players 30 533 1,067 1,600 2,133 3,200 4,267 6,433 8,533 20,833 30,000
Total Players 32 500 1,000 1,500 2,000 3,000 4,000 6,031 8,000 19,531 30,000
Calculation for maximum theoretical sv_maxrate = (upload bandwidth in kilobit per second  / 8 * 1000 / player number)

b is for bit
B is for Byte
There are 8 bits to a Byte

Networking speeds are always measured in bits and quoted asmultiples of 1,000 for Kilo, 1,000,000 for Mega and 1,000,000,000 forGiga.
Do not argue, that's just the way it is!
The really technical reason why data speeds are in multiples of1,000, or more to the point, do not generally correlate to binary mathsmeasurments, is that data is not sent down the wire, it is only asignal that represents data that is sent down the wire. That signal ismeasured in Hertz, and has nothing to do with binary maths, even thoughthe signal is representing binary data, and all you so callednetworking experts should know this, and if you don't, well you are notmuch of a networking expert, are you?
Can you tell that I am sick of this argument yet? :)
30,000 is the maximum sv_maxrate for SRCDS. That is why all the calculations above, max out at 30,000

Maximum theoretical updates per second a server must deal with for a given player number
  Total players --> 10 Players 12 Players 14 Players 16 Players 18 Players 20 Players 24 Players 28 Players 32 Players 40 Players
33 Updates/Second 330 396 462 528 594 660 792 924 1,056 1,320
50 Updates/Second 500 600 700 800 900 1,000 1,200 1,400 1,600 2,000
66 Updates/Second 660 792 924 1,056 1,188 1,320 1,584 1,848 2,112 2,640
100 Updates/Second 1,000 1,200 1,400 1,600 1,800 2,000 2,400 2,800 3,200 4,000
Calculation for maximum theoretical updates per second = (updates per second * player number)

This is why it is generally better to run at a higher fps_max so long as your server can cope.
I would suspect that 2,000 updates per second is the most aSRCDS process is ever going to realistically going to have to deal withdue to per player & tickrate/total player number considerations.
It is important to note that in SRCDS, fps = I/O per second.
So the goal of raising your fps_max is to keep a low ratio of server frames per second to updates per second
It is also important when designing a Gaming Network, that allyour network devices (Routers & Switches) can sustain thepackets/frames per second these setups can generate. That is to say,your Network might be fine with 1 SRCDS running on 1 box, BUT, running10 boxes with 6 SRCDS each, all with high rates, and then you realiseyou might have a problem!
Hardware Spec Example We run 6 x 16 Player SRCDS on DUAL Xeon 3.0GHz (or better) Serverswith 3GB of RAM with bonded dual 1Gb Switched and Load Balanced NetworkConnections into 1Gbps or 10Gbps BackBones with a 66 tickrate. So whenI say good hardware with good Network Connectivity, this is thebenchmark I am basing my opinions on.
Suffice it to say we could probably run 4 x 12player 100tickrate servers, BUT although the difference between 33 tickrate and66 tickrate is the difference between night and day, the differencebetween 66 tickrate and 100 tickrate is negligible on the Internet,when all issues are taken into consideration. Also some maps and playernumbers caused intermittent issues at 100 tickrate that a GSP does notreally want to have to worry about, especially when you can have 6 x 16player servers that run excellently at 66 tickrate! :)
Choke THE MAIN CAUSE OF BAD CHOKE IS A CLIENTS STEAM INTERNET CONNECTION SPEED BEING SET INCORRECTLY
Please ensure that all clients STEAM Internet Connection Speeds are setup correctly. See BAD CHOKE SOLUTION
Choke is quite simply the server wanting to send an update to the client, but cannot.
Notes regarding Netgraph Updates per second measurements you need to be aware of:
You won't get higher updates than;
a) The servers tickrate
b) The servers sv_maxupdaterate
c) As fast as your server fps allows (Limited by fps_max, hardware and the Kernel Timer Resolution)
d) As fast as your servers sv_maxrate allows
e) As fast as the client/server connection allows
f) As fast as the clients rate allows
g) As fast as the clients cl_updaterate allows
h) As fast as the clients fps allows (Limited by fps_max, hardware, and Refresh Rate)
h) Client FPS controls how fast the client can send updates to the server, this the OUT on the net_graph 3
NB: Other than tickrate, Choke is caused by any of theabove list of things not being large enough. This usually occursbecause the sv_maxupdaterate or cl_updaterate being higher than thesv_maxrate or rate allows, since the server will not send more data persecond than sv_maxrate or rate allows.
Fixing Clients Choke Besides making sure clients follow BAD CHOKE SOLUTIONand set their STEAM Internet Connection Settings correctly, the only 2Variables that are going to really help the clients choke problems are RATE and CL_UPDATERATE.
Net_graph 3 Explanation
1. fps is how many frames per second the client isrendering. This is limited by the clients fps_max setting or therefresh rate of the monitors vertical refresh rate if Vertical-Sync isenabled.

2. ping is:
a) netgraph ping is the round trip time for game packets, NOT including any tickrate or updaterate induced calculation delays
b) Scoreboard latency (ping) is one way trip latency (I have to find out in which direction)
c) rcon status command ping, well nobody really knows what this means yet, but I am aiming to find out.

IN is what is being received by you the client, FROM the server.
OUT is what is being sent by you the client, TO the server.

The IN & OUT both have 3 components, starting from left to right:

3. The size of the game packet in bytes being sent and received (Not sure if this includes UDP Segment + IP Packet overhead)

4. The Average amount of KiloBytes Per Second being Sent or Received of GameData + UDP Segment + IP Packet overhead

5. The Average amount of Updates being Sent or Received per Second

If you multiply 3. by 5. and then divide by 1000 you will get a close approximation of the value of 4. which includes rounding errors because 4. and 5. are only averages. So using the numbers we see above, for IN we get (154*102.4/1000)=15.7696 with the value shown in the picture above for net_graph 3 being 15.16. Meh, close enough. :)


The amount of IN Updates received by the client per second (controlled by cl_updaterate) will in most cases equal the servers tickrate, but will NEVER exceed:

Which ever is the smallest of those 3 numbers will determine the number you see for Updates per second RECEIVED by the client.

If the clients AND/OR servers bandwidth is not sufficient, or is limited by the clients rate or servers sv_maxrate, then the client will NOT see the INUpdates received by the client per second equaling the serversadvertised tickrate. This is one example of when the client will seechoke.
If the server does not have enough CPU to sustain the servers fps above the servers tickrate, the client will NOT see the INUpdates received by the client per second equaling the serversadvertised tickrate. This is another example of when the client willsee choke.

The amount of OUT Updates sent by your computer per second (controlled by cl_cmdrate) will NEVER exceed:

Which ever is the smallest of those 3 numbers will determine the number you see for Updates per second SENT by the client.

It may look like the OUT Updates sent by your computer per second does exceed the fps,but it reality it does not. It is that the net_graph 3 readings are notalways perfectly in sync or there are rounding errors in thecalculations, because the the two per second counts 4. and 5.shown in net_graph 3, are only averages. There is also the error in thenet_graph 3 that occurs when the Average Updates Received by you perSecond magically seem to exceed the servers sv_maxupdaterate, serverstickrate, and the clients cl_updaterate, which were all set to 100 atthe time the screenshot was taken above, despite what is shown in thepicture above.

6. Loss Are lost packets due to Network problems,either with your computers connection to your ISP, your ISP, or the ISPthat is hosting the Server or anywhere in between. If you have lossthen you will probably have choke. Do not bother trying to solve Chokeproblems if you have Loss problems. Resolving loss problems is done byfollowing standard Network Trouble Shooting Procedures. Get a friend tohelp you or call your ISP, or ask in the Game Server Providers Forumfor help. Helping you with network problems is outside the purview ofthis document, and people who know what they are doing get paid 3 or 4figure dollar amounts an hour to solve them.

7. Choke Is quite simply the server wanting to send youdata but cannot. The reason for this though are not always simple tounderstand, diagnose or fix. See the Choke explanation above.
8. You bring up your net_graph by typing net_graph 3 into console. You may find it helpful to centre the net_graph using the net_graphpos 2 command, and raising it a little so it does not overlay your HUD using the net_graphheight 100 command in console. The net_graphheight command is a function of your screen resolution, so you will need to adjust it accordingly with net_graphheight 100 working well for 1024x768. Increasing the value of net_graphheight makes the net_graph higher and Decreasing the value of net_graphheight lowers the net_graph.
Here is a little script you can put into your autoexec.cfg forcycling through the various net_graphs that will work in all Valvegames:
//netgraph script
alias graph "graph1"
alias graph1 "net_graphpos 2; net_graphheight 100; net_graph 1; alias graph graph2"
alias graph2 "net_graphpos 2; net_graphheight 100; net_graph 2; alias graph graph3"
alias graph3 "net_graphpos 2; net_graphheight 100; net_graph 3; alias graph graph4"
alias graph4 "net_graphpos 1; net_graph 0; alias graph graph1"
bind "r" "graph"
Obviously adjust net_graphheight and bind "r" where "r" is the keyboard key you use to cycle through the different net_graphs to suit your own personal preferences.

Important Information for both Players and Server Administrators

The Server will not send more data and/or updates than the Clientis setup to receive unless the clients violate the server minimums, inwhich case the servers sv_minrate and sv_minupdaterate will be used bythe client.
The Client cannot make the Server send more data and/or updates than the Server is set up to send
You should, after reading the entire article above, now knowwhat it is that controls what the Server & Client can and cannotsend & receive, how often, and why.
If you do not, you either did not read what I have written, orsome part of my explanation was not clear to you. Suffice it to say allthe information you need is in here, even if you do not realise it.
For those of you who are still struggling to comprehend the above, try the Noobies Guide to Netgraph & Ping.
Why don't my clients get 100 Updates a Second? Assuming you have set the tickrate correctly to 100 (in this example) and the server is in fact running at 100 tickate, the FIVE main causes of clients not receiving 100 Updates per Second are as follows:
There are more reasons than this, but you these are the main causes of not seeing as many updates as you might expect.
This whole guide, if you have read and understood it all, seeksto address how to resolve the issue of sending and receiving as manyupdates as you want your server to.
Finally, never discount that it is in fact a client side issuewith the client computer that is connecting to your server, unless ofcourse there has been a recent Valve SRCDS update, and everything hassuddenly inexplicably gone to hell.
For Client Side issues please refer to Fixes for FPS Problems with Counter-Strike and most other games
Solving the mystery of cl_interp_ratio The client side setting cl_interp (it is not suppose to exist any longer) has been replaced  by the client side setting cl_interp_ratio
cl_interp_ratio simply causes the interpolation delay to be calculated off the clients cl_updaterate (Theamount of updates the clients receive per second. This will not exceedthe servers sv_maxupdaterate or servers tickrate, which ever is thesmaller)
The outcome for this is as follows:
cl_interp_ratio 1.0 cl_updaterate 30 interpolation = 0.033
cl_interp_ratio 1.0 cl_updaterate 35 interpolation = 0.029
cl_interp_ratio 1.0 cl_updaterate 40 interpolation = 0.025
cl_interp_ratio 1.0 cl_updaterate 50 interpolation = 0.020
cl_interp_ratio 1.0 cl_updaterate 60 interpolation = 0.017
cl_interp_ratio 1.0 cl_updaterate 66 interpolation = 0.015
cl_interp_ratio 1.0 cl_updaterate 75 interpolation = 0.013
cl_interp_ratio 1.0 cl_updaterate 80 interpolation = 0.013
cl_interp_ratio 1.0 cl_updaterate 100 interpolation = 0.010

cl_interp_ratio 1.5 cl_updaterate 30 interpolation = 0.050
cl_interp_ratio 1.5 cl_updaterate 35 interpolation = 0.043
cl_interp_ratio 1.5 cl_updaterate 40 interpolation = 0.038
cl_interp_ratio 1.5 cl_updaterate 50 interpolation = 0.030
cl_interp_ratio 1.5 cl_updaterate 60 interpolation = 0.025
cl_interp_ratio 1.5 cl_updaterate 66 interpolation = 0.023
cl_interp_ratio 1.5 cl_updaterate 75 interpolation = 0.020
cl_interp_ratio 1.5 cl_updaterate 80 interpolation = 0.019
cl_interp_ratio 1.5 cl_updaterate 100 interpolation = 0.015

cl_interp_ratio 2.0 cl_updaterate 30 interpolation = 0.067
cl_interp_ratio 2.0 cl_updaterate 35 interpolation = 0.057
cl_interp_ratio 2.0 cl_updaterate 40 interpolation = 0.050
cl_interp_ratio 2.0 cl_updaterate 50 interpolation = 0.040
cl_interp_ratio 2.0 cl_updaterate 60 interpolation = 0.033
cl_interp_ratio 2.0 cl_updaterate 66 interpolation = 0.030
cl_interp_ratio 2.0 cl_updaterate 75 interpolation = 0.027
cl_interp_ratio 2.0 cl_updaterate 80 interpolation = 0.025
cl_interp_ratio 2.0 cl_updaterate 100 interpolation = 0.020

Clients can have higher cl_interp_ratio values to accomodate for packetloss & choke.
There are 2 server side variables that limit how large a clients cl_interp_ratio can be, these are:
"sv_client_min_interp_ratio" = "1" replicated - This canbe used to limit the value of cl_interp_ratio for connected clients(only while they are connected). -1 = let clients set cl_interp_ratioto anything any other value = set minimum value for cl_interp_ratio
"sv_client_max_interp_ratio" = "2" replicated - This canbe used to limit the value of cl_interp_ratio for connected clients(only while they are connected). If sv_client_min_interp_ratio is -1,then this cvar has no effect.
We will be using the defaults for now
The bottom line is this: interp is calculated off yourupdaterate. Change your updaterate and your interp will change, it isas simple as that!
P.S. This is only the theoretical interpretation of what issupposed to happen. Please do not attempt to blame the author if yourreality does not agree with the theoretical explanation.
P.P.S. This new information (18January2006) invalidates smallparts of the other sections of this tickrate guide, please take thisinto consideration. Thank You
Useful Links In conclusion I hope this helps clear up some of the mystery of setting up aserver with high tickrate, don't worry if it does not, I am stillasking questions myself.
Special Thanks to Alfred Reynolds and Martin Otten for their input that helped me put this guide together.
If you are still having problems with SRCDS then please refer to my Troubleshooting_valve_HLDS-SRCDS Guide
Cheers
Whisper
Whisper's Very Basic Competitive Counter-Strike War Strategy Guide
PostScript: Questions Remaining



歡迎光臨 玩樂天堂 pockyland (https://pockyland.tw/) Powered by Discuz! X3