On Wed, May 06, 2009 at 06:35:36PM +0200, Dominik Auras wrote: > Hi Eric, > > Thanks for the answer. > >> It's hard to say. If you've got a logic analyzer you can instrument >> the inner loop of the firmware and see if that's the bottleneck or not. > Unfortunately, I don't have a access to a logic analyer :( > > However, I made progress that I am going to share once it is tested and > cleaned up. > > Short summary: > When doing RX only, I am at 45 Mb/s (yes! decim=6 works without > underruns).
That's great! > On the TX side, I can't get above 32.7 Mb/s. Now I suspect > that this is a host side bottleneck. On the FX2, if using only one > direction, I am setting the GPIF to loop infinitely. With GPIFABORT=0xFF > to switch if the state changes. Hence there is no main loop left that > could be a bottleneck. The TX state machine now consists of 2 states, > where state one is the idle state, and state 2 transferring data (one > word per clock, as before). The 8051 core is completely out of the data > path. (Auto commit etc.) > Same for RX, except that a few more states were needed. > > When RX and TX are needed, the firmware is still faster, though the same > TX bottleneck appears (which is, of course, no big problem because we > already share USB bandwidth). > > Do you have, maybe, an idea why TX bandwidth is limited? Interestingly > enough, 32.7 Mb/s is the limit on my computer and my notebook. Not sure. Could be the EHCI controller, or the host driver, etc. > Of course, I made the tx loop on the host as short as possible, set > SCHED_FIFO and rtprio to 49, and played with fusb_nblock/size etc. Let us know what else you figure out! Eric _______________________________________________ Discuss-gnuradio mailing list [email protected] http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
