I respect people for giving good information, like James has done. I can understand that people want specific information. But what I don't get is if people get upset when they don't get what their looking for, really a lot of people are ignorant about a lot of things (me included, no I'm not to proud to accept my own or someone else's disabilities), and good specific information is hard to come by.
It's human nature to want to help out, so people who think they have some knowledge about a questions their bound to reply with it, in the end this knowledge can turn out to be partly correct or completely incorrect. I still don't see the point for people to get upset over this; if someone has read something somewhere about an issue someone here is asking about, and he shares it to try to help out. And then gets a load of arguing, really I still find that rude. Yes, I kind of have resolved it with James amicably. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Whisper Sent: vrijdag 9 september 2005 5:25 To: [email protected] Subject: Re: [hlds] Tick Rate Guide Updated -- [ Picked text/plain from multipart/alternative ] Geeze, some of you are so thinned skinned All I want, all I ever wanted, is very specific answers to quite specific questions, thus far up and until now, none of you have been able to answer these questions. Finally though, after chipping away and chipping away, somebody has come up with an explanation about one specific area that does make some sense and gives me at least, a deeper understanding of what it is I trying to achieve. The relatively minor banter between blkraven and James Tucker was such a non-issue and they even appeared to resolve it amicably in the end, and James actually gave this list some very useful information because of it. Dabosman, I don't like to debate, I just like to get straight answers that make logical sense, and so far nobody has provided a straight answer as to why 3 measurements of pings are at complete odds with each other. If people were happy to accept answers despite what all observable eveidence demonstrates, we would still think the Earth is the centre of the universe. On 9/9/05, Brian M Frain (eternal) <[EMAIL PROTECTED]> wrote: > -- > [ 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 > -- _______________________________________________ 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
