> > > Using the libusb library to bypass all software layers, I issue READ_10 > > commands for 8KB blocks. Sequential access gives me 7.8 MB/sec and random > > access gives me 3.1 MB/sec. I use libusb with usb-storage.c found here: > > http://svn.navi.cx/misc/trunk/grumpydisk/usb-storage.c > > Okay. You've bypassed all the software layers, so what you're seeing is > the performance limit of the hardware. Not much we can do to improve > that. > > > In the last async test that showed a 25% increase, I think the test was > > ending up using the disk cache so the performance went up a little. > > Maybe this was true for the Windows results also? By the way, using the > disk cache should give a tremendous performance improvement. Much more > than 25%. > > > I tried looking at timing information from usbmon and comparing it to timing > > information under Windows using sniffusb but the info is inaccurate due to > > logging overhead. I did not notice much except maybe under Linux bulk read > > packets are sometimes split into 2 4KB ones and in Windows are 8KB in size. > > Nonsense. The maximum size for high-speed bulk data packets is 512 bytes. > That's part of the USB specification. Maybe you're thinking of URBs > instead of packets? usbmon reports information about URBs, not about > packets, and so does sniffusb. > > > Linux sends the READ_10 command and then 2 bulk out packets, > > No, Linux doesn't send any bulk-out packets after the CBW for a READ > command. > > > and then > > receives 2 bulk in packets of 4KB. Windows sends the READ_10 command and > > then 1 bulk out packet, receives 1 bulk in packet of 8KB, and then sends out > > a bulk out packet, and receives another bulk in packet of a small size. > > Your description is completely wrong. In terms of URBs this is what > actually happens: > > usb-storage sends the 31-byte bulk-out CBW URB. Then it submits either a > single 8 KB bulk-in data URB or else two 4 KB bulk-in data URBs, depending > on whether or not your 8 KB buffer is located in physically continguous > memory pages. Those URBs show up on the bus as 16 back-to-back 512-byte > IN data packets, regardless. Then usb-storage requests a 13-byte bulk-in > CSW URB. > > Of course, when you use libusb to bypass usb-storage then the memory pages > _will_ be contiguous, so Linux will always use a single 8 KB data URB. > > Alan Stern
Sorry for confusing packets for URBs. I don't think it is a hardware limit because Windows gets 10 MB/sec on the random 8KB reads versus 3.4 MB/sec for Linux, no disk cache involved as I'm opening the file to the raw device, in Linux to /dev/sda, in Windows to \\.\PHYSICALDRIVE3. I could try readv to see if that helps but it won't help my application as I don't know which block to read beforehand, it is a B-tree lookup pattern. Is it possible the performance difference comes from having two 4 KB bulk-in data URBs versus a single 8 KB bulk-in data URB, and maybe having the second 4KB bulk-in data URB submitted before receiving the first 4KB bulk-out URB? Fred Shotton ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Linux-usb-users@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-users
