Date: Thu, 31 Jan 2002 18:03:07 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Eugene Panchenko <replicator@ngs.ru> Cc: hackers@freebsd.org Subject: Re: Clock Granularity (kernel option HZ) Message-ID: <3C59F75B.6F52F810@mindspring.com> References: <web-8711515@intranet.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
Eugene Panchenko wrote: > I've seen various postings on the Net where people reported > network-related and overall performance improvements caused > by settig HZ kernel option to 1000 (for example), that is, > reducing a tick size to 1ms for their FreeBSD and Linux > systems. This is a NETISR processing frequency hack. You can get the same effect by reducing the quantum clock, and not screwing around with HZ. > However, several problems seem to arise, such as > some device drivers do not include HZ in calculating their > timeout value, but simply assume HZ to be 100, and also some > utility programs such as top or ps take timing information > from the kernel in ticks, also assuming 10ms ticks, however, > most of these saying were related to Linux. How safe it is > to bump up HZ to, say, 1000 in FreeBSD (I use 4.5-STABLE)? > What pitfals will I encounter (drivers, top/ps)? FreeBSD already does this internally for profiling, so all the device drivers and everything are supposed to use the HZ value in their calculations. IF they don't, they are broken. There will be a minor issue of quick timeouts at the switch over point, in that the number of "ticks" that are expected is based on the frequency at the time the timer is instantiated, and the ticks per second going way up will cause them to fire much faster. This should be non-harmful, in most casess, since they should cause a retry (we would probably know by now from people like me who do extensive profiling that there was a problem, otherwise). > Is there are going to be [promised] performance increase? Probably not; it depends on how you measure performance. The time to establish a connection will go down, and the time to ACK will go down (the SYN cache obviates most of the wins, if that's the 4.5 snapshot you are using), and the time for a user space program will go down, if your system is I/O bound, and up if it's CPU bound. 8-). > Do I really need it? Are you running otu of memory? All you are doing is reducing the pool retention time. You should see an increase in the number of connections per second, etc., but it won't affect your throuput or your ability to move data, unless you end up getting some memory back that you were losing to pool retention before. > Thank you. Don't mention it. 8-). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3C59F75B.6F52F810>