Hi!
> > And there I was thinking "bandwidth reclamation" was
> > for optimizing bandwidth usage, not pessimizing it! :)
>
> USB bandwidth, other busses don't matter...
>
> But seriously, what should be the correct heuristic for that? Decreasing the
> reclamation duration leads to problems with some devices (as a posting
> recently showed...). No reclamation provides miserable USB bandwidth and
> depth first sequence has no fair scheduling.
[I asked if it is easy to switch to depth first... It really is: one define]
Is "no fair scheduling" really a problem?
I tried using simultenaously zip and usb-to-usb network, and did not
see any too bad problem.
Reading 11.5MB from zip normally (FSBR) takes 41 seconds.
With depth first (no FSBR), it takes 43 seconds.
With depth first (no FSBR) and scp file from remote, it takes 45.
With depth first (no FSBR) and ping -f remote, it takes 50.
With depth first (no FSBR) and scp file to remote, it takes 87 to 91 seconds.
That does not seem too bad, what about switching to depth first and
no FSBR as default?
(Is there some scenario when unfairness is unacceptable? I'd like to
test that -- my idea is that permutating devices on chain each
milisecond could provide neccessary fairness.)
Pavel
--
I'm [EMAIL PROTECTED] "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents at [EMAIL PROTECTED]
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
http://lists.sourceforge.net/lists/listinfo/linux-usb-devel
