Whisper wrote:
--
[ Picked text/plain from multipart/alternative ]
Well finally an answer that makes logical sense as to why default kernel
resolution servers fps seem to sit at around 64
:)
I didn't write the guide from the techincal perspective, although I'd
love
nothing more than to have all the technical knowledge to not only write
the
document but then explain the underlying logic for each and every step
of
the process.
Then we should begin. Off-list.
That being said, I also just want shit to work and I also was seeing at
the
time I originally wrote the thread in the STEAM forums every 2nd
question
related to tickrate with nobody able to produce a definitive answer as
to
how to actually make it work and why.
Exactly, and it is for this reason I have a strong appreciation for all
the hard work you have put in, and again you have my thanks for that.
My explanation of how rate sv_maxrate sv_minrate relate to each other as
well as sv_maxupdaterate sv_minupdaterate cl_updaterate relate to each
other
managed to confuse even the developers on how it works, and I am still
trying to work out how to explain it better to a less technical
audience.
Indeed, technical explanations in simple terms are hard. It is gerneally
best to stay away from abstractions and generalisations for the simple
reason that they do not expand well to include other, or more complex
ideas. There are many examples of this problem available in the archives
of most technical mailing lists.
Since the last netcode update, where Alfred announced that the cmdrate
and updaterate numbers should now properly correlate with packets per
second rates shown in net_channels I have found the technical
descriptions are now easy to create, and general explanation is much
simpler. Gone are the days when you had to set cl_updaterate 100 or
above to get 40-50 packets per second out of a 100 tickrate server in
certain scenarios. Nowadays, with sane settings on the server, the
client settings work as expected, and achieve predicable results. The
same goes for the server settings.
Just to let you know James, our GSP actually exists to cater primarily
to
broadband users, with the majority sitting on sub 50ms pings and some on
sub
10ms pings so to give them a good end user experience we tweak the
servers
up for broadband users with good connections and most of us do notice a
considerable difference between a 33 tickrate server with default rates,
and
a 66 tickrate server with 20000/100 rates.
Indeed you will. There is no dispute over proper rate selection here :)
If you look at the settings closely, you will notice that since the
netcode update, you can set sv_maxupdaterate 66 (I set 67/70 in most
places, as sometimes it still sends a little more than the tickrate).
There are no more updates to be sent than the ticks, so 100 is slightly
overspecified. This does not cause an issue of course, as it's merely a
cap, and doesn't change anything that occurs in the data flow in this
scenario.
On 9/8/05, James Tucker <[EMAIL PROTECTED]> wrote:
Whisper wrote:
--
[ Picked text/plain from multipart/alternative ]
Please feel free to write you own or tell us precisely where you think
we
are going wrong and why.
I have detailed this inline in each mail. Your guide is generally good,
and is targeted for a different audience than this list. I would be more
than happy to assist you in adding/correcting anyhting. Many thanks for
actually producing it.
I'd love nothing that a logically correct and complete reproducable
guide
on how to get the most out of a server.
Unfortunately, I just agreed to spend most of my time keeping my
information to myself. You have others to thank for that.
As some of us have come to find out Valve can sometimes be completely
open
about certain issues and on others they completely clam up like we
we've
mentioned the mad cousin that nobody ever talks about.
Indeed. I got a t-shirt too.
If in fact THE DEFAULT TIMER RESOLUTION OF THE WINDOWS KERNEL IS 7.8ms.
why
do our servers only get around 65fps even though fps_max is clearly set
and
defaulted to 300 unless you change it?
Ah, well you see, 65fps isn't 60Hz :)
Typcially (as a general, but not accurate rule) srcds does not run at
greater than (kernel timer resolution/2)fps. This is true of the linux
builds aswell, which more accurately hit 50fps for a 10ms timer which is
the default on 2.4.x branch kernels. FYI - most linux srcds hosts now
use a 1000Hz, or 1ms resolution on linux platforms.
On windows, the timer resoution is around 7.8ms by default, which is
around about 128Hz, which is around about double 65fps. Now clearly, the
correlation is the same, as the code is the same, and the problem is the
same.
srcds clearly contains some timer dependant code, that is referenced at
least twice in one frame. This creates an artificial frame limit, as the
processor will block busy-waiting untill that poll, or will yeild to
other threads, but either way, will not process frame data until the
timer poll.
_______________________________________________
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
http://list.valvesoftware.com/mailman/listinfo/hlds
--
_______________________________________________
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
http://list.valvesoftware.com/mailman/listinfo/hlds
_______________________________________________
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
http://list.valvesoftware.com/mailman/listinfo/hlds
