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
