> > > Using async brought the performance of random access 8KB reads up 26% to > > about 4.3 MB/sec. Still a long way off the Windows speed. > > > > -fred > > > > > > > Frederick Shotton wrote: > > > > In conducting tests on a 4GB USB 200x memory stick, I find that using > > Linux > > > > 2.6.17 reading 8KB blocks I get 12MB/sec for sequential access and > > 3MB/sec > > > > for random access. The interesting thing is that under Windows with the > > same > > > > memory stick I get 10MB/sec for both sequential and random access. My > > goal > > > > is to get the fastest random access speed under Linux. > > > > > > > > I have delved into the internals of the usbstorage driver and tried > > various > > > > settings such as the GO_SLOW flag, but none of them help. I have also > > tried > > > > bypassing the usbstorage driver using libusb and got the same > > performance > > > > numbers. > > > > > > > > Any ideas? > > > > > > > How do you mount it? you probably have the sync flag.. if you use > > > async it will be much faster. > > > > > > mount -o async /dev/usbstick /mnt/point > > Most of the performance you're worried about is determined by the higher > layers of software, not by the USB stack. That's why the mount flags make > such a big difference. > > Another aspect of the difference has to do with how you program the random > access test. Do you use lots of read commands? Have you tried using > readv instead? The results will also depend on how large the individual > data blocks are. Linux works most efficiently when you transfer blocks > whose size is a multiple of 4 KB. > > If you want _really_ detailed timing information, use the usbmon facility > (instructions in the kernel source file Documentation/usb/usbmon.txt). > > Alan Stern >
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 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. 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. Linux sends the READ_10 command and then 2 bulk out packets, 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. 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
