you can also change the tickrate with sv_maxupdaterate and sv_maxcmdrate. -tickrate only gave/gives the maximum possible values for those cvars, afaik.
question is, to what value will valve limit the fps. if they will chose some value higher than the tickrate, it will not be so nice (because fps=tickrate is still optimal), if they chose it to be exactly the tickrate some others might get problems if their servers cannot run that fps stable... (I guess that still can happen?)
(07-25-2011, 06:14 PM)BehaartesEtwas Wrote: you can also change the tickrate with sv_maxupdaterate and sv_maxcmdrate. -tickrate only gave/gives the maximum possible values for those cvars, afaik.
question is, to what value will valve limit the fps. if they will chose some value higher than the tickrate, it will not be so nice (because fps=tickrate is still optimal), if they chose it to be exactly the tickrate some others might get problems if their servers cannot run that fps stable... (I guess that still can happen?)
Well they lately locked the FPS limit down to 500, so i think (and hope) that they will head that way. :-)
the reason fps is limited to variable 500 fps is because they added more sleep, before it only slept 1 ms between frames, now it sleeps 1ms on top of another X milliseconds depending on two unknown factors at this point. when i removed the new sleep function it worked same as before, 1000 fps, when thats removed you get 10000.
about your statements, the server is ALWAYS running at the specific tick rate you set, regardless of fps (lower fps than tick will choke the timing and it won't be the same as manually setting the tick rate) and regardless of your max update rates/cmdrates. that's just limiting the max that clients can use, not what the server is currently at. the engine converts your tick rate value to decimal and it uses that as a base, then on top of that you can change the console variables to your wishes but they don't change the actual tick rate. lots of disassembling and research in the hl2 source code and orange box and goldsrc has taught me tons about how the frame rate and ticks work. yet some idiot had to badmouth me in the goldsrc forum
(07-26-2011, 04:59 AM)click4dylan Wrote: the reason fps is limited to variable 500 fps is because they added more sleep, before it only slept 1 ms between frames, now it sleeps 1ms on top of another X milliseconds depending on two unknown factors at this point. when i removed the new sleep function it worked same as before, 1000 fps, when thats removed you get 10000.
about your statements, the server is ALWAYS running at the specific tick rate you set, regardless of fps (lower fps than tick will choke the timing and it won't be the same as manually setting the tick rate) and regardless of your max update rates/cmdrates. that's just limiting the max that clients can use, not what the server is currently at. the engine converts your tick rate value to decimal and it uses that as a base, then on top of that you can change the console variables to your wishes but they don't change the actual tick rate. lots of disassembling and research in the hl2 source code and orange box and goldsrc has taught me tons about how the frame rate and ticks work. yet some idiot had to badmouth me in the goldsrc forum
You are wasting time 'reverse engineering' the server fps. Just enjoy the game.
@click4dylan: that's not true. you even don't need a disassembler to find that out, as an early hl2 beta source code can be found in the net (and such things did not change).
the engine is calculating a new world snapshot (sometimes also misleadingly called a tick) every frame (sic!), only the decision which (or if any) clients that snapshot is to be send is based on the cl_updaterate (which is clamped to sv_min/maxupdaterate of course). Those updates are not sent synchronously, even if all clients would have the same updaterate.
if you don't believe this, tell me, what should be the difference between a server running with -tickrate 100 but sv_maxupdaterate 66 and a server running with -tickrate 66, in terms of sending/receiving network packets (assuming a server still having the -tickrate option of course).
you're just limiting what the server can send/receive, not how many snapshots are actually taking place, it will take -tickrate snapshots but only send/receive the sv_maxupdaterate/sv_maxcmdrate, the rest are just dropped but the cpu resources for taking those dumped snapshots is still going on
my server with a -tickrate of 100 but a max updaterate/cmdrate of 33 full with 32 people uses an entire core of my cpu, while -tickrate 33 with a max updaterate/cmdrate of 33 with a full server only uses about 15% (out of 25% for 1 core)
(07-26-2011, 07:35 PM)click4dylan Wrote: you're just limiting what the server can send/receive, not how many snapshots are actually taking place, it will take -tickrate snapshots but only send/receive the sv_maxupdaterate/sv_maxcmdrate, the rest are just dropped but the cpu resources for taking those dumped snapshots is still going on
my server with a -tickrate of 100 but a max updaterate/cmdrate of 33 full with 32 people uses an entire core of my cpu, while -tickrate 33 with a max updaterate/cmdrate of 33 with a full server only uses about 15% (out of 25% for 1 core)
If you lower the fps down to 33, the amount of snapshots taken, will also be set to 33. It won't work out ticks with no frames in it.
![[Image: 1308107839.png]](http://www.speedtest.net/result/1308107839.png)
