On Tue, 24 Apr 2001, Martin Diehl wrote:
> There is an IDLE_TIMEOUT = 50 msec used to disable FSBR. In some
> contradiction to its name it is measured from the submission of the
> urb, i.e. does not care whether we are really idle or not.
After being able to do real testing I just want to confirm what I've said
yesterday:
Yes, extending or disabling the IDLE_TIMEOUT makes 64kB sized bulk
transfer always happy - no spurious loss of fullspeed bandwidth with uhci
anymore. As explained in the last posting I do believe this static timeout
is a suboptimal solution - for both uhci flavours.
My suggestions:
- either restarting idle timeout counter whenever some progress is
detected for the active transfer - if this is possible?
- or changing the timeout from global constant to a new member of
urb->hcpriv. Using some magic like (10 + transfer_length / 1000 * 5)
(i.e. 10msec + 5msec/KB) as individual fsbr-timeout. So the transfer
would loose FSBR-grant if it used less than about 20% of it - which
wouldn't hurt so much in this case.
Other numbers are possible of course - f.e. 50msec + 2msec/KB would
prevent the fsbr-timeout from getting shorter than what it is now (so
nothing should brake) and still preserve FSBR-grant for a 64kB transfer
which uses only 40% of maximum bandwidth.
Anyway - sane bulk transfers should not make any asssumptions of bandwidth
they get, so IMHO this is "only" a performance improvement, not a bugfix.
Comments?
Martin
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
http://lists.sourceforge.net/lists/listinfo/linux-usb-devel
