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

Reply via email to