Yes, I fail to see how this has become useful any more to this list ... And has degraded into a debate apparently. I had similar type conversations with 'Whisper' awhile back about a similar issue (ping issue on the 'tab' scoreboard) .. And eventually had to just drop the conversation out of respect for the list.
Apparently, 'Mr. Whisper' likes to debate so much, he should have been a politician. At least he would have an audience for it. I agree with James here, either post something useful to the list .. Or take it 'off-list' and have your so-longed-for discussion .. And attempt to prove yourself correct . Since this is the only thing it seems you may be after here. As for the rest of us, I value the good information I normally receive here . And actually appreciate the useful feedback that I get from other server admins. I too have good information to offer .. But I also try to have a 'listening ear' so that I don't always throw my own opinion around as the only fact there is. Best Regards, Kevin > Yup, create a filter for the subject line. > > LDuke wrote: > > -- > > [ 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 > > > > > > --__--__-- > > _______________________________________________ > To unsubscribe, edit your list preferences, or view the list > archives, please visit: > http://list.valvesoftware.com/mailman/listinfo/hlds > > > > End of hlds Digest > _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds
