On Wed, Aug 21, 2013 at 10:53:32AM -0700, Simon Gornall wrote: > > On Aug 21, 2013, at 10:39 AM, Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: > > > On Wed, Aug 21, 2013 at 10:36:18AM -0700, Simon Gornall wrote: > >> Hi there, > >> > >> I'm in the process of designing a VME=>USB interface, and I wanted to > >> use the FT232H, but according to FTDI, the throughput on Linux is only > >> ~9MBytes/sec using current kernels. In the past, it was ~40MBytes/sec. > >> Sadly my Arm board is delivered running Linux 3.4.29 > > > > Why did it drop? What caused the regression? How was this measured? > > You have as much information as I have. I have requested more detail... > > Given the information below, I'd guess the regression was between > 2.6.27-57 and 2.6.28-3. As to what caused it, I have no idea. I'm new > to USB drivers, so I have some learning to do... > > Given that the company probably wouldn't *want* to claim that their > high-speed interface was slow as molasses, I'm assuming that the > throughput was measured in the same way both before and after the > regression and done by piping data as fast as possible in one end and > reading it as fast as possible at the other end. > > I'm in the process of designing a test-pcb which I can do some more > investigation with. I'll be able to plug it into an i7-based linux > box, a 1GHz ARM-7 embedded board, and an i7-based Mac. I'll write a > simple program to run on all of these which reads bulk data as fast as > it can, and I'll be feeding data into the FT232H at the other end at > 60 MHz, modulo its FIFO begin full. Once I've got that data I'll > report it back, but it'll take a few weeks to get the board designed, > made, and the program written and tested. > > If I can, I'll try reverting the OS on the linux PC to see if I can > narrow down where the regression occurred. That would be great to find out, thanks. > >> I don't really want to go back to the "olden days" of kernel 2.6.27-57 > >> - I'm not even sure it's possible on my embedded ARM board, so I was > >> wondering if anyone knew the reasons for such a drastic bandwidth > >> reduction. If it's something I can live with in my embedded situation, > >> I'd prefer to revert the change and lose whatever functionality was > >> gained by slashing the bandwidth by 4. > >> > >> Basically I need to be able to put 20 MBytes/sec through the USB port. > >> The FT232H parts are very attractive because they offer a simple > >> FIFO-style interface and one doesn't have to implement an entire USB > >> stack, which is much harder when you don't have a CPU ... > >> > >> Cheers > >> Simon. > >> > >> Mail from FTDI: > >> ---8<---8<---8<--- C u t h e r e ---8<---8<---8<--- > >> > >> Simon: > >> > >> You could use Sync FIFO mode, but I’m afraid there is another “gotcha” > >> to be aware of - with newer Linux kernels (>2.6.28-3), Sync FIFO > >> throughput is limited to 9 MByte/sec > >> > >> With the older kernels (2.6.27-57 and older) Sync FIFO will run at 40 > >> MByte/sec. Since you are using ARM Linux, there is a good chance you > >> have an older kernel. > > > > I have no idea what this is referring to at all. Is that just due to a > > driver change in the ftdi_sio driver, or something else? > > I was hoping there was a "we changed it because..." reason. If you > were unaware of the problem, I guess there's little you can do to fix > it :) > > I'm not sure if this helps, but the driver they're talking about is > the D2XX driver. Apparently this is needed to put the device into > synchronous FIFO mode. I don't see a "d2xx" driver in the kernel source tree, where can this driver be found? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
