> > These numbers tell me that there's a huge overhead (at least 8ms) when > > starting a transaction. Is this normal? > > There's a per-transaction overhead, sure ... I'd expect max 2 msec (and more > typically about 1 msec) comes from the host controller (which is "OHCI" not > "OCHI"). Other delays can come from usb-storage and scsi ... there are > multiple tasks involved.
Thanks for all your replys. It's ok to have a per transaction overhead, only the 8ms seems to be too much. > > The other problem is that the kernel is busy while waiting, if I set > > the blocksize to 512 in my application the computing performance of > > the system decreases dramatically. > > Then don't use 512 bytes!! You're basically doing block-at-a-time I/O, > where each block involves multiple task switches. Likely it's the task > switching that chews the most CPU overhead. > > There's a reason that block I/O systems avoid small blocks. They've > been tuned for large blocks. Now it may be that the small-block speed > here is lower than it should be, but you should never be surprised to > see that small-block transfers go slowly. I share a few details about the system. The ARM9 cpu is running at 120MHz, and has a uClinux kernel (MMU-less). According to Hyok S. Choi the context switching time is slightly less than a standard (MMU) Linux system: http://opensrc.sec.samsung.com/document.html I have to implement an audio player with a "play while seek" feature. I achive this by seeking 16-64k (depending on the bitrate and the length of the track) and then play 40msec, then seek again, and so on. Reading the file sequentially and dropping the parts I don't need doesn't work because the required transfer speed exceeds the 900 kbyte/sec our usb host can do. This seek thing has to work forward and backward. With the 8+ msec busy wait the decoding one sec of "seeking audio" takes just a bit longer than one sec... :( So I'm a bit stuck... One important thing: the same application (play while seeking) runs on the same hw, on uCOS II, which has the OHCI and mass storage drivers ripped from the linux kernel (this butchery was not done by us), so the hw is powerful enough to do this. I'll try the verbose debug, and the usbmon things first, and i hope i'll find something. Any other ideas where should i look? Thnaks! George ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel