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
