From owner-freebsd-hackers Sat Nov 15 21:51:56 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id VAA20740 for hackers-outgoing; Sat, 15 Nov 1997 21:51:56 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from trojanhorse.ml.org (mdean.vip.best.com [206.86.94.101]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id VAA20731 for ; Sat, 15 Nov 1997 21:51:50 -0800 (PST) (envelope-from jamil@trojanhorse.ml.org) Received: from localhost (jamil@localhost) by trojanhorse.ml.org (8.8.8/8.8.5) with SMTP id VAA00433 for ; Sat, 15 Nov 1997 21:51:39 -0800 (PST) Date: Sat, 15 Nov 1997 21:51:39 -0800 (PST) From: "Jamil J. Weatherbee" To: freebsd-hackers@freebsd.org Subject: AIOX Analog driver statistical analysis Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I conducted a number of test trials doing 12bit analog sampling across 48 channels with this board and driver. The system is freebsd-2.2.5 stable with aiox driver, AIO8-P analog board and 3 external multiplexers, 48 channels total are being sampled. This is a NexGen-100 Disklessly booting system. I don't know what the computational/io performance is compared to something like a PPro but I plan on running it on a PPro-180 and finding out. The cpu time is for the driver and a process using sleeping on select to determine which channels to read. Aggregate Sample Frequency Percent Cpu Time 32 hz 2% 62.5 hz 3% 125 hz 6.2% 250 hz 12.5% 500 hz 25% 1000 hz 45% 2000 hz 90% 16000 hz Saturated But No Overruns The performance is linear (below saturation) and the sample freq to percent cpu has a 99.9% correlation. The equation: %Cpu = 0.9477 + 0.044606*(Sample Freq) Gives a very good approximation of %Cpu I wonder just how much faster a PPro or Pentium is then a NexGen machine (this is in purely integer performance since I am not doing any calculations in the user process). Keep in mind that select returns as soon as a single entry is available in any channels fifo. I am thinking about adding an ioctl() that would allow the user to specify a select() trigger point, say they could tell the driver to not do a selwakeup() unless the fifo is more than half full. Of course using blocking I/O with huge buffers solves this a bit (and I will be testing that also), but that precludes any kind of virtual multitasking in a single code thread for multiple channels.