SRCDS Steam group


FPS soon to leave
#16
You can't change the tickrate without an tickrate enabler. -tickrate was removed in the orangebox update.
Reply
#17
(07-23-2011, 07:58 PM)michael_sj123 Wrote:  You can't change the tickrate without an tickrate enabler. -tickrate was removed in the orangebox update.

you can still change it on day of defeat source freely, and on CSS i dont use third party plugins i change it myself using OllyDbg
Reply
#18
(07-23-2011, 07:58 PM)michael_sj123 Wrote:  You can't change the tickrate without an tickrate enabler. -tickrate was removed in the orangebox update.

You can just lower the fps to 33.33, that will lower the tickrate aswell. Rolleyes
Slå den med jeres fiberforbindelser...

[Image: 1308107839.png]
Reply
#19
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?)
http://www.fpsmeter.org
http://wiki.fragaholics.de/index.php/EN:Linux_Optimization_Guide (Linux Kernel HOWTO!)
Do not ask technical questions via PM!
Reply
#20
(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. :-)
Slå den med jeres fiberforbindelser...

[Image: 1308107839.png]
Reply
#21
Well it is not locked, sometimes my FPS bumps to 900 (with fps_max = 0)
Reply
#22
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
Reply
#23
(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.

http://leaf.dragonflybsd.org/~gary

“The two most common elements in the universe are hydrogen and stupidity.”








Reply
#24
@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).
http://www.fpsmeter.org
http://wiki.fragaholics.de/index.php/EN:Linux_Optimization_Guide (Linux Kernel HOWTO!)
Do not ask technical questions via PM!
Reply
#25
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)
Reply
#26
(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.
Slå den med jeres fiberforbindelser...

[Image: 1308107839.png]
Reply
#27
inb4 another argument about fps, tickrate and some other bullshit

This thread will be locked if you all continue on this path.
Reply


Forum Jump:


Users browsing this thread: 2 Guest(s)