From owner-freebsd-hardware Fri Jul 31 14:44:00 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA05960 for freebsd-hardware-outgoing; Fri, 31 Jul 1998 14:44:00 -0700 (PDT) (envelope-from owner-freebsd-hardware@FreeBSD.ORG) Received: from oldyeller.comtest.com (comtest.hits.net [206.127.244.117]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA05955 for ; Fri, 31 Jul 1998 14:43:56 -0700 (PDT) (envelope-from randal@comtest.com) Received: from graphics.comtest.com (graphics.comtest.com [206.127.245.194]) by oldyeller.comtest.com (8.8.8/8.8.8) with SMTP id LAA20872; Fri, 31 Jul 1998 11:41:50 -1000 (HST) (envelope-from randal@comtest.com) Message-Id: <199807312141.LAA20872@oldyeller.comtest.com> From: "Randal S. Masutani" Organization: ComTest Technologies, Inc. To: john@ece.arizona.edu (John Galbraith) Date: Fri, 31 Jul 1998 11:48:07 -1000 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: new GPIB driver Reply-to: randal@comtest.com CC: FreeBSD-hardware@FreeBSD.ORG, Mike Smith , Peter Dufault In-reply-to: <199807312010.NAA18443@burdell.ece.arizona.edu> References: <199807230013.RAA02438@dingo.cdrom.com> (message from Mike Smith on Wed, 22 Jul 1998 17:13:40 -0700) X-mailer: Pegasus Mail for Windows (v3.01b) Sender: owner-freebsd-hardware@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 31 Jul 98, at 13:10, John Galbraith wrote: > 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? As I mentioned it was raw throughput of 600KBytes/sec. I am sending 60 blocks of 64Kbyte size transfers. Using GPIB-Spy on the receiving station(Win95) to measure time for each block of 64K. Source computer: P166 FreeBSD 2.2.6, NI-GPIB/TNT ISA. Dest computer: P166 Win95, NI-GPIB/TNT ISA. Wrote a DOS program to just read 64Kbytes blocks of data. > 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()? Mike can best answer these questions. :) > 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). I have been playing with the T1 bus timing and it does make a difference from setting it to 350ns, 500ns, 2us. With the 2us timing the transfers slow down to about 300Kbyte/sec. > 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. Well, I can get from Win95 to Win95, using demand DMA mode transfers about 1.3Mbytes/sec, again using GPIB-Spy on the receiving station to monitor timing. If we can get DMA to work on FreeBSD it should improve transfers very much I hope. > 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 I will have the new NI-GPIB/TNT+ board in today. This will allow me to run the GPIB Analyzer software so I can see the timing on the bus much better and see also everything else going across that bus. Randal ------------------------------------------------------------------------- ComTest Technologies, Inc. 3049 Ualena St., Suite 1005 Honolulu, Hawaii 96819 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hardware" in the body of the message