Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 31 Jul 1998 13:10:07 -0700
From:      john@ece.arizona.edu (John Galbraith)
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
Subject:   Re: new GPIB driver
Message-ID:  <199807312010.NAA18443@burdell.ece.arizona.edu>
In-Reply-To: <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
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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199807312010.NAA18443>