Just a brief cap of what I have found working with drivers doing this.
First, the highest tx/rx rate we have seen on a 32bit/33MHz bus is 120MB/s.
The canned I/O rate of PCI 32/33 is 132 MB/s. 64/66 is 4x this ~533 MB/s.
This is on a pci design we did in house.
If you wish to go the DMA to userspace there are some problems I encountered
that I was not able to over come, perhaps someone more skilled than I could
offer suggestions. First, without scatter gather DMA ability, you will find
yourself limitted to page size contigious blocks of userspace memory.
The overhead of breaking DMAs into 4k blocks was prohibitive for me, I now use a
round robin array of 128KB buffers in kernel space and do the data copies while
the next DMA is occuring, but this is less of an issue if you support sg.
The other thing I'd note is that with a streaming device and a network device,
there would be alot of PCI bus contention, Manfred's idea of two PCI busses is
sound. Watch out for 66MHz busses to solve your problem as every one I've seen
is a 3.3V PCI bus, your hardware might not support this.
Have you looked at other solutions?
On that scale, large data aq. boxes make more sense for the buffering. Then you
can read them out at a higher rate than the data stream. The only reason I
mention this is my company produces a boxes to do this.....
Jonathan Brauer
> > I've been contracted to write a driver for a high speed data aquisition
> > interface. High-speed, in this case, means that it will (almost)
> > saturate half of the PCI bus (I don't know the exact data rate for this
> > application, but the interface has a advertised 130Mbyte/s maximum
> > throughput) with incoming data. The data is supposed to go out on an
> > gigabyte ethernet card, using the second half of the PCI bandwidth.
>
> Perhaps a board with 2 pci buses would be better?
Well, I have no control over this. And, there also exists 64bit and
66Mhz PCI....
What I know is that this is more or less a trial and the real show will
start somewhere in 2005, if I got it right. So by then the data rates
will go up, both on the requirement side and on the
what's-possible-in-hardware side. The final application is daunting...
something like 65000 measurement points, which is
reduced/compressed/whatever to require _only_ 1500 of these
interfaces!!!
> > Sometimes the direction will be reversed, but not very often and (as far
> > as I understand) not so very-high-speed.
> > The interface is a bus-mastering PCI thing, currently for a 33Mhz, 32bit
> > bus. The technical req. are that it has to be a zero-copy driver and the
> > interface will use DMA to deliver the data. So I'm faced with writing a
> > driver that can do DMA to directly to userland.
>
> DMA to userland is tricky, do you really need that?
> It's far easier if you allocate a buffer in kernel space (a few mb), the
> userland program then mmaps the kernel buffer. Your driver uses DMA to
> the kernel buffers. The sound drivers do that. If you cannot modify the
> userland app, then you must use the kiobuf functions [2.3 or an add-on
> patch for 2.2]
Thanks for this info. Sounds good and workable.
Unfortunately it MUST be a streaming driver, as the measurement time is
not defined and definately not short enough to just store everything in
memory. But, I guess, the kernel has enough memory to allocate some
buffers.
I just read a note about someone using the same interface ASIC
(different application), also with linux, that they did a 410Mbyte DMA
into memory! However, they did only a one-time measurement, no
streaming.
And there's a good chance I'll also need to do (part of) the userland
app, so there is really no problem there.
As addition, I just found out that it's basically a uni-directional
interface, with only four lines going back to the data source, but those
are really slow. Think like a maximum of .5Mbit/s or such. So for me
it's only the input I have to worry about.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Apr 23 2000 - 21:00:17 EST