Date: Fri, 31 Jul 1998 11:48:07 -1000 From: "Randal S. Masutani" <randal@comtest.com> To: john@ece.arizona.edu (John Galbraith) Cc: FreeBSD-hardware@FreeBSD.ORG, Mike Smith <mike@smith.net.au>, Peter Dufault <dufault@hda.com> Subject: Re: new GPIB driver Message-ID: <199807312141.LAA20872@oldyeller.comtest.com> 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)
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199807312141.LAA20872>