On Fri, 15 Apr 2005, Konstantin Kletschke wrote:
> Am 2005-04-15 16:47 +0300 schrieb Olav Kongas: > > time if=a_16MB_file_on_stick of=/dev/null bs=16k > > > > yielded here 717 kiB/s. > > [EMAIL PROTECTED] ~ # time dd if=/dev/sda of=/dev/null bs=16k count=1024 > 1024+0 records in > 1024+0 records out > real 0m 41.91s > user 0m 0.04s > sys 0m 1.32s > > [EMAIL PROTECTED] ~ # time dd if=/dev/zero of=/dev/sda bs=16k count=1024 > 1024+0 records in > 1024+0 records out > real 0m 41.24s > user 0m 0.00s > sys 0m 2.78s > > Are these ~390 kiB/s? > > 16*1024/42 > 390.09523809523809523809 > > I not sure, I am only able to hex-calculate recently :D > > > By the way, for the current driver version the maximum > > possible transfer rate when performing bulk-only transfers > > to/from a single device is 812.5 kiB/s. > > Why do you know that so exactly? There is a macro MAX_TRANSFER_SIZE_FULLSPEED defined in the driver, which is the max. number of databytes scheduled for a single frame. Currently it is 832. If that many bytes are transfered in every frame, we get: 832 B/ms = 832000 B/s = 812.5 kiB/s To see transfer rates close to that maximum, the following must happen in every frame when in the middle of processing a large URB: 1. SOF, transfers on USB bus, ATL interrupt 2. entering irq handler, reading the transfer results from FIFO RAM, writing new data to FIFO RAM, exiting irq handler (at next SOF, cycle begins at 1.) If 2. takes too long so that the next SOF is missed then the transfers will take place only in every second frame and the transfer rate drops abruptly to about half of the maximum possible. I guess that is what's happening in your case. In the middle of large data transfers, steps 1-2. take about 90% of the frame time on my platform. There are two things you can do to improve the transfer rate in your case, assuming you don't have other time-consuming irq handlers installed on your system. First, you can try to optimize the delay between chip register accesses. If you use your own platform delay function, try to recalibrate it. You may also want to recheck the memory controller timings for the chip access. Second, you can redefine the MAX_TRANSFER_SIZE_FULLSPEED to 704 instead of 832. This would still allow transfering 4kiB in 6 frames (with 832 it can be done in 5 frames). If then the transfers will take place in every frame, you should see rates well above 390 kiB/s. Olav ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel