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
