-- [ Picked text/plain from multipart/alternative ] Well said LDuke but we shouldn't have to take such drastic measures. A few are ruining the good for the rest. It is you same guys always bickering that ruins this list.
On 9/8/05, James Tucker <[EMAIL PROTECTED]> wrote: > > 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 > -- _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds
