From owner-freebsd-hardware Fri Jul 31 14:05:09 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA27618 for freebsd-hardware-outgoing; Fri, 31 Jul 1998 14:05:09 -0700 (PDT) (envelope-from owner-freebsd-hardware@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 OAA27598 for ; Fri, 31 Jul 1998 14:05:05 -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 NAA00537; Fri, 31 Jul 1998 13:59:57 -0700 (PDT) Message-Id: <199807312059.NAA00537@dingo.cdrom.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: john@ece.arizona.edu (John Galbraith) cc: mike@smith.net.au, fcawth%jjarray.umd.edufcawth@jjarray.umd.edu, randal@comtest.com, dufault@hda.com, FreeBSD-hardware@FreeBSD.ORG Subject: Re: new GPIB driver In-reply-to: Your message of "Fri, 31 Jul 1998 13:10:07 PDT." <199807312010.NAA18443@burdell.ece.arizona.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 31 Jul 1998 13:59:57 -0700 From: Mike Smith Sender: owner-freebsd-hardware@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Well, I put the the first post of my code in > ftp.freebsd.org/pub/FreeBSD/incoming/gpib-galbraith.Jul29-98.tar.gz. > > Randal says he is up to 600K/sec on with the modifications to the old > driver. I am not up to that yet, but there are a thousand things that > I still have to look at before I give up. Randal, what size of > transfers are those, and how are you measuring your data rate? > > I measure my data rate by putting two GPIB cards in the same machine > (I only have one machine to play with at a time 8-( ) and having one > send data to the other. This means that the data has to get in AND > out of the kernel on the same machine as I run my benchmark. There > are a bunch of things that I don't know about this process. First of > all, how do you get userland data into the kernel the fastest? Would > this be with uiomove()? The fastest way is to map the user buffer into the kernel's address space, but that's expensive. uiomove is the next best way to go. > What block sizes are reasonable, and are > there problems with very big or very small transfers? When you say "block" I prefer you refer to the size of each individual transaction. Each read/write call requires a context switch into the kernel and back out again, and these cost. The larger the transaction, the lower the cost per unit data. > Right now, I am > still using ioctl() to write data. I am not quite sure how the data > gets into the kernel, other than the fact that it does. Does the > operating system do this automatically with the ioctl() mechanism? Yes; the data are copied in as part of the ioctl process. > Should I expect an improvement when I move this functionality to > write() and read()? This depends on where your overheads are. Note that the ISA bus bandwidth will ultimately become a bottleneck for you, as you're only using one bus for two cards. -- \\ 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-hardware" in the body of the message