From owner-freebsd-current  Mon Aug 30 15:58: 7 1999
Delivered-To: freebsd-current@freebsd.org
Received: from alcanet.com.au (border.alcanet.com.au [203.62.196.10])
	by hub.freebsd.org (Postfix) with ESMTP id B8512152CE
	for <current@FreeBSD.ORG>; Mon, 30 Aug 1999 15:57:55 -0700 (PDT)
	(envelope-from jeremyp@gsmx07.alcatel.com.au)
Received: by border.alcanet.com.au id <40344>; Tue, 31 Aug 1999 08:54:22 +1000
Date: Tue, 31 Aug 1999 08:55:49 +1000
From: Peter Jeremy <jeremyp@gsmx07.alcatel.com.au>
Subject: Re: HEADS UP
In-reply-to: <19990830173120.30486@right.PCS>
To: jlemon@americantv.com
Cc: current@FreeBSD.ORG
Message-Id: <99Aug31.085422est.40344@border.alcanet.com.au>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

Jonathan Lemon <jlemon@americantv.com> wrote:
>On Aug 08, 1999 at 03:01:32PM -0700, Julian Elischer wrote:
>> I don't want to sound ungrateful, but couldn't we have defined these in
>> terms of Usecs and translated?
...
>  I think that having it in units of usec is
>probably better than msec; it provides more in the way of 
>"forward compatability",

Given a 32-bit integer, it also puts a much lower limit on the
maximum.  This is likely to bite on TCP keep-alives - currently they
are set to 2 hours.  We can't represent 2 hours as usecs in 32 bits.

> and allows for a larger HZ.

Not really.  The only problem is that the rounding errors get more
noticable as the number of units approaches HZ.  This is an artifact
that should be pointed out in the description - eg if you ask for
2msec on an Alpha, you'll probably get 1.66msec.

Peter


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message