Skip site navigation (1)Skip section navigation (2)
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>