On Wed, 12 Jul 2006, Gyorgy Szekely wrote: > Hi, > I'm using the linux OHCI driver with an ARM based SoC. > CPU: ARM 940T > Kernel: uClinux 2.6.14 > > I've made some transfer benchmarks, and the results were a bit > strange. The benchmark is sequential read from an USB flash stick, 7.5 > MB file right after reset. I've made multiple passes with and without > directio (O_DIRECT flag when opening a file), changing the kernel > readahead with posix_fadvise(), and the read blocksize (the buffer > size passed to read()). > I've measured the time it takes to complete a read() call, and > recorded the average read time, the worst(longest) time and the > overall time to read the whole file (using gettimeofday). > > Here are my results: (sequential read, DirectIO) > blocksize avg(us) wc(us) total > 512 9000 28988 132sec > 2048 11057 30976 41sec > 16384 25697 61010 12sec > > I also tried with normal IO, telling the kernel to double the > readahead buffer (posix_fadvise(POSIX_FADV_SEQUENTIAL)), and this way > it took only 8 seconds to read the whole file, which is the maximum > speed the hardware can do. > > I have problems with the directio. The difference between the first > and the second pass that i read 4 times as many data at a time, but it > takes only 2 ms longer to read a block. Similarly comparing the first > and the third pass: 32 times as many data, less than 3 times longer > per block. > > These numbers tell me that there's a huge overhead (at least 8ms) when > starting a transaction. Is this normal? > 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. > > My application works with large files on the usb stick (i can't read > the whole file into ram), and makes "random seek, short read" > sequences, so the fileIO performance is very poor because of this > "overhead". I implemented some kind of own caching but it's still no > good. > > Unfortunately i'm not too familiar with the usbhost/mass store > drivers, and the blockdev subsytem of the kernel, that's why i'm > asking for your help. > Any advice or hint is welcome!
Trying to analyze stuff like this, which is affected by several layers of software, is always hard. To start with, you can find out exactly what's happening at the USB level. If you build a kernel with CONFIG_USB_STORAGE_DEBUG set, then the system log will include some very verbose messages telling just what happens. Or if you build a kernel with CONFIG_DEBUG_FS and CONFIG_USB_MON set, you can follow the instructions in Documentation/usb/usbmon.txt to get a more condensed view of the same information. In general, I would expect that the transfer sizes at the USB level are not directly connected with the block sizes you use at the application level. Alan Stern ------------------------------------------------------------------------- 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
