[Discuss-gnuradio] USB speed data point
Hi - I'm bringing up a board http://recycle.lbl.gov/llrf4/ with a hardware and software USB stack based on and (for this purpose) equivalent to the GNU Radio design, and measured its USB data transfer capabilities more carefully than I have done before. There is a distant possibility someone on this list might make use of the result, so here it is: Reading only, on a lightly loaded AMD64 3500+ machine (2.2 GHz, dual-channel RAM), I can sustain 35.7 MByte/sec without errors. Attempting 35.8 MByte/sec, packets get dropped left and right. The host end of the USB is a VT8237 Chipset, seemingly run in EHCI mode by Linux-2.6.16 (Debian sid 2.6.16-2-amd64-k8). I think the limitation is on the 8051 end. One 512-byte packet takes 8.53 microseconds to cross the USB channel, and the 35.7 MByte/sec sustained rate implies the 8051 sets up the next packet in only 5.81 microseconds. I don't think there is any pipelining at this level. - Larry ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USB speed data point
ldoolitt == ldoolitt [EMAIL PROTECTED] writes: ldoolitt Hi - I'm bringing up a board http://recycle.lbl.gov/llrf4/ ldoolitt with a hardware and software USB stack based on and (for this ... Some hints for your part list: - consider the Spartan 3E family versus Spartan3. 3E is often considerably cheaper - look at the actual lead time for the INA138 -- Uwe Bonnes[EMAIL PROTECTED] Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 -- ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USB speed data point
Uwe - On Fri, Oct 27, 2006 at 08:35:22PM +0200, Uwe Bonnes wrote: ldoolitt == ldoolitt [EMAIL PROTECTED] writes: ldoolitt Hi - I'm bringing up a board http://recycle.lbl.gov/llrf4/ ldoolitt with a hardware and software USB stack based on and (for this Some hints for your part list: - consider the Spartan 3E family versus Spartan3. 3E is often considerably cheaper - look at the actual lead time for the INA138 Thanks for your comments. The FPGA accounts a tiny fraction of the board cost. It does look like a XC3S1200E-4FTG256C would shave the cost down a little, and add a few more gates besides. There are non-trivial changes in the pinout, though. I'm not sure I want to deal with that on a respin. The INA138 was in-stock at Digi-Key when I laid out the board, and we managed to get enough to build the first six (although they were removed, because I made a pin numbering mistake on the layout). When Digi-Key first ran out of stock, I looked for alternatives, but couldn't find any I liked. - Larry ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USB speed data point
I think the limitation is on the 8051 end. One 512-byte packet takes 8.53 microseconds to cross the USB channel, and the 35.7 MByte/sec sustained rate implies the 8051 sets up the next packet in only 5.81 microseconds. I don't think there is any pipelining at this level. You're probably right. It's known that the SSRP (which had no FPGA, just a USB interface and an ADC) got higher thruput, because it programmed the USB interface registers to automatically stream data through without the intervention of the 8051. (It knew all the traffic was inbound, so didn't need the option to switch directions on the bus.) We could get a similar speedup in the USRP (or LLRF) by having the 8051 jump to different inner loops when doing input-only, output-only, or both input and output over the USB bus. Think of it as hoisting one of the invariant decisions out of the inner loop. John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
