Let me ask again if anyone would object to the following...

A couple comments: I've reconsidered the need to ever adjust the value
of tick. Also, expanding the expression for TICKADJ, as below, makes
it abundantly clear what it's trying to do. It's especially important
to round _up_, rather than _down_, for cases where HZ is large (>500);
otherwise, TICKADJ goes to 0.

Dropping tickadj to 1/8 of its previous value results in a substantial
decrease of the average offset from the selected peers, in my tests on
a 486dx4-100, 486dx2-66, and an AMD K5-380. On machines which are
already marginal for running NTP, the call to adjtime() may rarely
complete before the next one -- this will be obvious, as the daemon
will either step frequently or fail to sync at all. This is why
TICKADJ should be adjustable. Ports with 1000 Hz clocks but high
interrupt latency might also benefit from a higher value of TICKADJ.


Index: param.c
===================================================================
RCS file: /cvsroot/syssrc/sys/conf/param.c,v
retrieving revision 1.35
diff -c -r1.35 param.c
*** param.c	2000/04/15 16:49:35	1.35
--- param.c	2000/06/04 12:24:38
***************
*** 97,105 ****
  #define	MAXFILES	(3 * (NPROC + MAXUSERS) + 80)
  #endif
  
  int	hz = HZ;
  int	tick = 1000000 / HZ;
! int	tickadj = 240000 / (60 * HZ);		/* can adjust 240ms in 60s */
  int	rtc_offset = RTC_OFFSET;
  int	maxproc = NPROC;
  int	desiredvnodes = NVNODE;
--- 97,109 ----
  #define	MAXFILES	(3 * (NPROC + MAXUSERS) + 80)
  #endif
  
+ #ifndef TICKADJ
+ #define	TICKADJ		((500 + (HZ - 1)) / HZ)
+ #endif
+ 
  int	hz = HZ;
  int	tick = 1000000 / HZ;
! int	tickadj = TICKADJ;
  int	rtc_offset = RTC_OFFSET;
  int	maxproc = NPROC;
  int	desiredvnodes = NVNODE;