Very sorry to add some experience data without any graphs, but I haven't had time to set em up yet. I thought my experiences might be of some interest anyway :
RootServer with the following configuration : AMD Athlon64 X2 4800+ "Windsor" (as such, it comes with 2048kByte 2nd lev. Cache) 2048 MB Kingston DDR2-667 Ram Following are the results of the version checks : Ubuntu 6.06.1 LTS dapper Linux 2.6.17.13-K8 #3 SMP PREEMPT 1000 Hz support is active. So far, we are running 2x CS:Source normal with 20 slots and 1x CS:Source GunGame with 14 slots. All 3 servers are running with Tickrate 100 and have 500 FPS (as u know, it always depends on when you are giving the server the stats command, but most of the time it will show 500 or 499). I haven't been reported any real lag-problems, although the server will get performance issues if running longer than 3 days without a restart (that should be something we all know about too, I guess). TOP is reporting as usual very weird CPU stats, being the one server at 82% and the other two at around 60% ... connect to any of the servers and you won't notice any performance issues tho ... so my guess is that top still is showing totally wrong rates (and it has, imho, always been like this ;-) Memory is no issue at all ... maximum is one of the 20 slots server using about 20% ... Lemme know if u wanna know anything else (BESIDES graphs, as I don't have any yet !). Greetinx, matteo. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Erik Hollensbe Sent: 05 November 2006 17:25 To: [email protected] Subject: Re: [hlds_linux] srcds performance On Nov 5, 2006, at 5:55 AM, William Warren wrote: > that's no so much an issue with LINUX IME As I've always understood it, the HZ parameter is an interval used to determine when the kernel checks to see if it needs to respond to any IRQ's. For instance, setting a low HZ on a server that does a lot of hardware access is a really, really good idea, like for a squid server, or database server. That was the reason the original poster mentioned lock contention. Anything that keeps your processes waiting in the run queue is going to cause problems. (Load Average is the average number of processes in the run queue) The longer it takes for your kernel to respond to interrupts, there will be more that will be there each time, making more tasks wait at once and generally increasing latency as the queue is emptied less often. Linux in particular is very fickle about load averages. While you can normally get a shell on another unix, after hitting about 80 load avg you'll be lucky if you can ping a Linux box and get a response back. I guess what I'm trying to say, is that the "HZ" parameter is an issue regardless of what free unix you're using, and what it comes down to is how your drivers use interrupts. FreeBSD at least has an option to make many of it's network drivers poll-centric instead of interrupt driven, allowing you to push the HZ through the roof for tasks that are rarely disk oriented (a web application that does no local disk access would be a good example, or a router, or a CS server). This is a compelling reason (among others) to have srcds with syslog support. I'm not sure how linux handles it, but it's worth looking into to see if linux polls its network devices to see if they have data waiting in the buffer. It would be a dramatic performance improvement. -- Erik Hollensbe [EMAIL PROTECTED] _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
