-- [ Picked text/plain from multipart/alternative ] Pretty much the same as us really, we just go for 66tick, have tried 33 & 100, and 66 seems to be the sweet spot for least amount of problems (100tick maybe more client issues as well though I often suspect).
On 4/27/06, Stuart Stegall <[EMAIL PROTECTED]> wrote: > > This is a multi-part message in MIME format. > -- > [ Picked text/plain from multipart/alternative ] > Those are our recommendations for competition servers, but we wish the > leagues would allow other cl_interp #s, but it's not up to us. > > For public servers, we just cannot recommend 100 tickrate. We just get > too many complaints door and other problems (since the September update > I believe). For pubs we just recommend 66 tickrate. > > Whisper wrote: > > -- > > [ Picked text/plain from multipart/alternative ] > > This is what we do currently: > > > > Windows OS > > Kernel Timer Resolution 1000Hz > > 100 tickrate > > 600 fps_max > > 30000 sv_maxrate > > 5000 sv_minrate for small servers 7500 for 40 player servers > > 100 sv_maxupdaterate > > 0 sv_minupdaterate (because of that strange lag problem if the fps drops > > even for an instant and then goes straight back to 500fps) > > > > We enforce cl_interpolate 1 and cl_interp 0.1 with zBlock (We have to > cater > > for users from 56Kbps to 24000Kbps connections who can be up to 4000KM > away > > from the servers) > > > > We also enforce ranges of rate values on clients mostly so people are > not > > blaming us for their shit house in game playing experience > > rate 6000 - 30000 > > cl_updaterate 35 - 100 > > cl_cmdrate 35 - 100 > > > > As much as you may like to quote the official documentation, the reality > > does not always match what the official documentation says is supposed > to > > happen i.e. bugs or "features" that remain undocumented. > > > > I for one would almost kill for a complete Game Packet, UDP Segment, IP > > Packet break down of SDRDS/HLDS client server communications along with > the > > effects of changing various settings for highly optimised low latency > > lossless high speed LAN networks to the unoptimised slowest worst case > > scenario networks rather than using trial and error as the method for > > verifying the best for the circumstances settings. > > > > On 4/28/06, James Tucker <[EMAIL PROTECTED]> wrote: > > > >> I think the bigger issue is people not keep up to date with > >> documentation and updates, and meanwhile misunderstanding the netcode > >> in general. I moved away from this mailinglist for a long time due to > >> the continual pointless arguments of this nature. I think the > >> documentation is clear, if you read valves documentation in their > >> wiki, then read carefully what each cvar says as you type it without a > >> value. > >> > >> There are things I still see very commonly abused though (why I'm > here): > >> > >> 1. There is no maximum to rate or sv_maxrate. Read the cvar docs and > >> compare to the cl_cmdrate/cl_updaterate cvar docs. Attention to detail > >> people, and don't read old CS 1.6 docs for advice on the Source > >> engine. > >> 2. cl_smooth is still being recommended set to 0 by many people - this > >> was fixed YEARS ago now (check the update logs), and the server does > >> cl_smooth 1, so if you have cl_smooth 0 on your client, your view WILL > >> DIFFER from the servers view. > >> 3. Optimising with client settings far from defaults is ALWAYS going > >> to seperate you from Valves internal testing procedures (how they > >> optimise the game) which will use some form of the defaults! > >> 4. rate and sv_maxrate are still being set to low by most people due > >> to these imaginary 'limits'. This causes choke. Beware setting them > >> too high causes loss. If you don't know the difference you need to > >> learn. > >> 5. cl_cmdrate is being recommended too high still. In the same way > >> that you don't set a server sv_maxupdaterate to 100 if the server is > >> doing 64fps on a 100tick setup, you don't set cl_cmdrate higher than > >> your average client fps if you don't want client generated choke > >> (which will drop bullets!). > >> 6. No accounting for protocol overheads - check the size of the real > >> data flow to and from your servers, there's some un-accounted for data > >> there than when you get a pile of clients running updaterates at your > >> tick, you'll start to use more data than you were originally expecting > >> - I've been recommending using 10-20% boundaries to my clients for > >> years anyway. > >> 7. Use QoS services to prioritize your data! > >> 8. 100 tickrate is above and beyond the call of duty. There are very > >> few humans who can quantize anything at 100Hz. Furhtermore, latency > >> flux is greater than 0.01ms in almost ALL cases of internet server, > >> therefore this is quite silly anyway, it's wasted data as the next > >> tick could well arrive before the last! > >> 9. cl_interp - I don't know how, after good references now have decent > >> pagerank and are referenced in a lot of core reference docs that > >> people don't get this yet. And yet there are now server side plugins > >> that lock you to cl_interp 0.01 - this only feels good if you set > >> cl_smooth 0, suprise suprise, because it's extrapolating, not > >> interpolating. At a client fps of 20-30 you might not even notice, but > >> it's there. The interpolation, prediction, and smoothing engines WORK > >> REALLY WELL, so leave them on, and as has been noted in the past, the > >> server generally runs them ALL, so for a server-client aligned world > >> view, you want to run them. > >> 10. cl_smoothtime is a capping value, like sv_maxrate and rate - they > >> don't affect anything until the controlled variable approaches the > >> value of the cvar. In other words, sv_maxrate 20000 generally does > >> nothing if you use cl_updaterate 10. > >> 11. dump net_graph! net_graph does not give you accurate values. I've > >> seen servers out there which register 0.1 loss permanently in > >> net_channels, and net_graph shows nothing at all. The client-server > >> consistency is heavily affected by this loss and many of you would > >> never find out whats causing it. > >> > >> > >> Locking variables does not solve any of the above problems. The > >> problems of the communities are: > >> > >> 1. Ego - players can't accept having a bad day. > >> 2. Sheep - players listen too much to random forum posts rather than > >> finding out real information - reading 'rate' and 'cl_updaterate' and > >> understanding in detail what the cvar documentation says and doesn't > >> say is a perfect example. > >> 3. Name clobbering - as there are common cvar names between cs 1.6 and > >> cs:s there is alot of clobbering of names and people read the wrong > >> documentation, what's worse is this has spread to the hl2dm > >> communities. > >> 4. HSPs / GSPs don't generally understand much better and often give > bad > >> advice. > >> 5. Variables outside of workable settings should not be able to be > >> set. Setting cl_cmdrate < 10 no longer works. Setting rate really low > >> works really fine aslong as your server admin hasn't set moronic > >> settings and your client doesn't do something like cl_interp 0.01. > >> 6. Lack of cohesion in thinking - there are plenty of setups that will > >> feel smooth, if you're going to choose someones advice to follow, > >> follow all of it, not a part from here a part from there. > >> 7. Major leagues carry community thinking - some of the major leagues > >> have very incorrect settings which they are pushing out as "league > >> standards". Please, get some computer scientists or engineers to do > >> the real engineering work, inference without understanding is called > >> guessing. > >> > >> > >> On 26/04/06, Biscuits <[EMAIL PROTECTED]> wrote: > >> > >>> It would create more as well. > >>> > >>> On 4/27/06, Andreas Grimm <[EMAIL PROTECTED]> wrote: > >>> > >>>> and why ? > >>>> > >>>> -----Ursprüngliche Nachricht----- > >>>> Von: [EMAIL PROTECTED] > >>>> [mailto:[EMAIL PROTECTED] Im Auftrag von Hans Vos > >>>> Gesendet: Mittwoch, 26. April 2006 16:27 > >>>> An: [email protected] > >>>> Betreff: Re: [hlds] Re: Server tickrate suggestions > >>>> > >>>> VALVE should just lock the tickrate on 66, would save us all a lot of > >>>> headaches. > >>>> > >>>> -- > >>>> Kind regards, > >>>> > >>>> Hans Vos > >>>> > >>>> > >>>> _______________________________________________ > >>>> 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 > >>>> > >>>> > >>> -- > >>> Biscuits > >>> > >>> _______________________________________________ > >>> 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
