-- [ 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. 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. 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. 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. 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
