From owner-freebsd-hardware Fri Jul 31 13:09:33 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA16052 for freebsd-hardware-outgoing; Fri, 31 Jul 1998 13:09:33 -0700 (PDT) (envelope-from owner-freebsd-hardware@FreeBSD.ORG) Received: from ece.arizona.edu (ece1.ece.arizona.edu [128.196.28.166]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id NAA16041 for ; Fri, 31 Jul 1998 13:09:31 -0700 (PDT) (envelope-from john@ece.arizona.edu) Received: from burdell.ece.arizona.edu by ece.arizona.edu (SMI-8.6/SMI-SVR4) id NAA15546; Fri, 31 Jul 1998 13:09:11 -0700 Received: by burdell.ece.arizona.edu (SMI-8.6/SMI-SVR4) id NAA18443; Fri, 31 Jul 1998 13:10:07 -0700 Date: Fri, 31 Jul 1998 13:10:07 -0700 From: john@ece.arizona.edu (John Galbraith) Message-Id: <199807312010.NAA18443@burdell.ece.arizona.edu> To: mike@smith.net.au, fcawth@jjarray.umd.edufcawth@jjarray.umd.edu, randal@comtest.com, dufault@hda.com, mike@smith.net.au CC: FreeBSD-hardware@FreeBSD.ORG In-reply-to: <199807230013.RAA02438@dingo.cdrom.com> (message from Mike Smith on Wed, 22 Jul 1998 17:13:40 -0700) Subject: Re: new GPIB driver 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()? What block sizes are reasonable, and are there problems with very big or very small transfers? 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? Should I expect an improvement when I move this functionality to write() and read()? Second, I don't know if the bottleneck is the operating system or the GPIB bus itself. It could be that the data rate is limited by the bus and how I have the bus timing configured (which I haven't optimized at all yet). DMA - This seems to work on the send, but I sometimes get dmacheck errors and kernel panics which I haven't fixed yet. The read doesn't work, but I don't know if it is actually the DMA that is broken or the bus not syncronizing after the read. I sometimes have that problem with one of my cards even when I am not using DMA, but not the other. Finally, there is a #include problem when configuring this into the kernel which doesn't exist when doing it as an LKM. I just noticed this, and haven't had a chance to fix it. It is probably no big deal. John To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hardware" in the body of the message