From owner-freebsd-hackers Wed Apr 2 03:32:28 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id DAA24147 for hackers-outgoing; Wed, 2 Apr 1997 03:32:28 -0800 (PST) Received: from florence.pavilion.net (florence.pavilion.net [194.242.128.25]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id DAA24141 for ; Wed, 2 Apr 1997 03:32:22 -0800 (PST) Received: (from joe@localhost) by florence.pavilion.net (8.8.5/8.8.5) id MAA01784; Wed, 2 Apr 1997 12:31:12 +0100 (BST) Message-ID: <19970402123111.58518@pavilion.net> Date: Wed, 2 Apr 1997 12:31:11 +0100 From: Josef Karthauser To: Joerg Wunsch Cc: hackers@FreeBSD.ORG, gbeach@cybernet.com Subject: Re: Internal clock References: <3340C326.6150@cybernet.com> <19970401151947.61221@pavilion.net> <19970401203429.XR37988@uriah.heep.sax.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.64 In-Reply-To: <19970401203429.XR37988@uriah.heep.sax.de>; from J Wunsch on Tue, Apr 01, 1997 at 08:34:29PM +0200 Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Tue, Apr 01, 1997 at 08:34:29PM +0200, J Wunsch wrote: > As Josef Karthauser wrote: > > > I'm using gettimeofday which returns: > > > > struct timeval { > > long tv_sec; /* seconds since Jan. 1, 1970 */ > > long tv_usec; /* and microseconds */ > > }; > > > > I've no idea of the actual system resolution, ... > > RTFM clocks(7). I have read this, although I still wasn't too clear about the above. The fact that a system clock ticks in useconds doesn't mean that there's going to be an interrupt every usec. I didn't get a chance to look at the source either, as it was a late night hacking midi code. > > BTW a question to the hackers... does anyone have any plans for > > adding a real-time scheduling class, aka threads under solaris? > > There's already a pseudo-realtime scheduling class available, see > rtprio(1). This has, of course, nothing to do with threads at all, > nor will it be true realtime, since there's still the problem that > scheduling doesn't happen while running in kernel context (i.e., the > kernel cannot be preempted -- Solaris seems to have gone great lengths > to create some preemption points for long-time running kernel > functions). I found the solaris way a bit of a nightmare. I wanted to set up a cyclic midi in buffer, but unfortunately the serial devices seemed to run somewhere below the real time class :( I'm now reviving the old solaris project and porting it to FreeBSD (that now being my platform of choice ;) [and I can drive midi directly, instead of out of a 19200k serial port into an Amiga which did the baud rate translation.] Joe -- Josef Karthauser Technical Manager Email: joe@pavilion.net Pavilion Internet plc. [Tel: +44 1273 607072 Fax: +44 1273 607073]