From owner-freebsd-hackers Fri Jul 31 13:56:16 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA24876 for freebsd-hackers-outgoing; Fri, 31 Jul 1998 13:56:16 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from dingo.cdrom.com (dingo.cdrom.com [204.216.28.145]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA24871 for ; Fri, 31 Jul 1998 13:56:15 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost [127.0.0.1]) by dingo.cdrom.com (8.8.8/8.8.5) with ESMTP id NAA00498; Fri, 31 Jul 1998 13:55:30 -0700 (PDT) Message-Id: <199807312055.NAA00498@dingo.cdrom.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: chanders@timing.com (Craig Anderson) cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Using FreeBSD for data acquisition? (long) In-reply-to: Your message of "Fri, 31 Jul 1998 12:53:12 MDT." <199807311853.MAA04187@count.timing.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 31 Jul 1998 13:55:30 -0700 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > My company is considering using FreeBSD for a data acquisition > application. We want to know if an upper bound be placed on the > latency of an application reading data from a data acquisition > board? FreeBSD is being considered first and then commercial RTOS's > will be tried. No, there is no upper bound. Your response time will vary depending on a large number of factors, eg. swap activity, other driver activity, hardware errors, etc. > A test project is being done. The project uses an ISA data > acquisition board. The board interrupts 500 times a second, an 8 > byte data block is read from the board on each interrupt. > > There is a driver lkm for the board: a) driver buffers 4k data > blocks. b) driver interrupt function reads 1 data block, stores > data block in buffer, wakes the reader. c) driver read function > waits for at least 1 data block, returns minimum of requested data > blocks and available data blocks. > > A test application: a) Loops forever requesting 4096 data blocks. > b) Saves the number of data blocks returned on each read to a file. > > Because the interrupts/data blocks arrive at 500 HZ, I am interpreting > the number of data blocks returned on a read as a measure of read > latency of the application. If the read returns 50 data blocks, it > has been .1 second since the last read. (50/500 = .1) > > Below are code fragments from the test application. The rtprio() > call is to put the process into RTP_PRIO_REALTIME. Should this > make a difference? Is the code correct? You haven't included enough code to be certain that your device driver is working properly. I suspect that it might not be. > 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. > I'd like comments from FreeBSD hackers out there. Can an upper > bound be put on the read latency? An upper bound of about .100 seconds > is probably acceptable. Why is a read latency of .100 seconds (50 > data blocks) so common? Should RTP_PRIO_REALTIME help? Does FreeBSD > 3 have realtime features that will help? Is there a problem with > the code or a better approach? In a soft-realtime project I was working on last year, we used the rtprio facility to expedite the data handling process. We were able to meet a hardware-mandated 100msec delay with light loading under some circumstances, but this was not sustainable if disk I/O was being performed (we were saving incoming data at >1MB/sec). There are enhanced realtime facilities in FreeBSD 3.0 which would help in some cases, however it's not clear from your message what your real goals are. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message