-- [ Picked text/plain from multipart/alternative ] Is there a way I can automatically send this thread to my junkmail box and still recieve the rest of the HLDS mailing list?
On 9/8/05, James Tucker <[EMAIL PROTECTED]> wrote: > > > > 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 > -- _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds
