-- [ Picked text/plain from multipart/alternative ] Dual CPU Dual Core Opeterons FTW :p
1 SRCDS per core effectively I would get lynched if I tried to pull 100 tick off our public CS:S servers now On 4/28/06, Ian mu <[EMAIL PROTECTED]> wrote: > > -- > [ 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.6and > > >> 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 > -- _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds
