-- [ 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: hlds@list.valvesoftware.com > > > 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
