From owner-freebsd-hackers Sat Aug 1 03:13:02 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id DAA27037 for freebsd-hackers-outgoing; Sat, 1 Aug 1998 03:13:02 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from hda.hda.com (hda-bicnet.bicnet.net [208.220.66.37]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id DAA27024 for ; Sat, 1 Aug 1998 03:12:59 -0700 (PDT) (envelope-from dufault@hda.hda.com) Received: (from dufault@localhost) by hda.hda.com (8.8.5/8.8.5) id GAA13588; Sat, 1 Aug 1998 06:10:44 -0400 (EDT) From: Peter Dufault Message-Id: <199808011010.GAA13588@hda.hda.com> Subject: Re: Using FreeBSD for data acquisition? (long) In-Reply-To: <199807312055.NAA00498@dingo.cdrom.com> from Mike Smith at "Jul 31, 98 01:55:30 pm" To: mike@smith.net.au (Mike Smith) Date: Sat, 1 Aug 1998 06:10:43 -0400 (EDT) Cc: chanders@timing.com, freebsd-hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL25 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > At the end of the message is histogram data for a test run of about > > 15 hours. I plot the data with gnuplot, using a logscale for y. > > Note that the longest read is 480 (480/500 = .960 seconds). Note > > that the most common read is 50 (50/500 = .100 seconds). > > This would tend to indicate a possible problem with the interaction > between your interrupt handler and the read handler, but it's > impossible to tell without seeing the code. .1 seconds is the round robin scheduling interval. It appears the wakeup from the driver isn't preempting the current process, but waiting until the next roundrobin call. As far as I can tell, wakeup should preempt it. We do large continuous data collection on FreeBSD. However, we don't try to meet any latency requirements - the data is time stamped by the different pieces of hardware and we just don't lose any of it. It is difficult to guarantee response in FreeBSD without: 1. Having a way to know you missed your deadline, either in hardware or using the CPU time stamps, for debugging your system and testing new releases; 2. Doing your latency critical work in the kernel. You still have to keep an eye out for misbehaving device drivers turning off interrupts, etc. Peter -- Peter Dufault (dufault@hda.com) Realtime development, Machine control, HD Associates, Inc. Safety critical systems, Agency approval To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message