Date: Thu, 9 Jul 2009 05:47:00 +1000 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Mike Silbersack <silby@freebsd.org> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r195430 - head/sys/kern Message-ID: <20090709045726.A46151@delplex.bde.org> In-Reply-To: <200907080109.n6819CEn033840@svn.freebsd.org> References: <200907080109.n6819CEn033840@svn.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 8 Jul 2009, Mike Silbersack wrote: > Log: > Increase HZ_VM from 10 to 100. While 10 hz saves cpu time > under VM environments, it's too slow for FreeBSD to work > properly. For example, ping at 10hz pings about every 600ms > instead of about every second. It shouldn't be that bad -- the error should be at most 2 ticks in the worst case, and only 1/2 a tick on average. I thought that only the worst case is normal for ping. Apparently the 2-tick error gets doubled somewhere (maybe internally in select(2) and again in ping). I use a modified ping that makes ping attempt to send a packet at every multiple of the specified interval, instead of waiting for the specified interval "between" sending each packet as documented. All sleeps and timeouts in FreeBSD except ones generated by periodic itimers give an interval that is at least as large as the specified interval (unless interrupted by a signal). ping uses select(2) timeouts, so (HZ) timer granularity necessarily gives intervals of between 0 and 1 ticks too long (average half a tick too long), and due to misimplementation details they are up to 2 ticks too long (average 1.5 ticks too long?). ping doesn't try to compensate for this and probably shouldn't, since it couldn't do better than the implementation while maintaining the minimum interval. It could use periodic itimers. My version still uses select(), but checks timestamps so as to determine how much to reduce the interval to recover from previous intervals being too long. IIRC, it does this without using extra syscalls. However, a periodic itimer could do it with fewer than the normal number of syscalls. It would restore the use of SIGALRM, and avoiding SIGALRM is an important optimization by fenner, but I think using periodic itimers would make using SIGALRM best again. I should also use a modified ping that makes ping -f actually flood. A flood ping would send packets as fast as possible. ping -f only sends them when they come back, or 100 times per second, whichever is more. 100 times per second may have been a high rate in 1980 but it isn't now, but with your HZ = 10, 100 times per second is 20 times higher than is done. With HZ = 100, 100 times per second is only 2 times higher than is done. ping -i allows setting a smaller interval than ping -f (down to ping's internal bogus granularity of 1 ms), but small intervals won't actually work unless HZ is large, due to external timer granularity. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090709045726.A46151>