Hi Matt,
> > I can see why multi-buffering might be useful to handle scheduling overruns
> > in controlled-bandwidth i/o (periodic transfers otherwise require real-time
> > scheduling) but that reasoning doesn't apply to bulk or control transfers.
>
> Well, where I sit, there is a large gain from multi-buffering for bulk
> transfers.
I think you mean queued bulk transfers, not multi-buffering ... or maybe
you're reading something different than what I meant to say.
> The issue people see is that it takes a long time (relatively) to go from
> one scatter-gather segment to the next. As USB 2.0 deploys, the amount of
> bandwidth wasted from this increases dramatically.
Going from one segment to the next shouldn't be noticable; the
EHCI hardware does it automatically. It can happen in the middle
of a micro-frame quite easily, with no mandated CPU overhead.
Just queue up those segments ...
Yes, to get full advantage from EHCI, you're going to want to fill that
queue up pretty full. At 60 MByte/sec (peak/theoretical) it'll empty
quickly. (Well ... maybe after I figure out why it's not working! :) If we
assume most high speed storage devices handle 512 byte max bulk
transfers, table 5-10 of the usb 2.0 spec says that's about 6.5 KB
per microframe, around 52 KB/frame (frame = msec) at best.
> This is why I would like to be able to, at least, submit multiple bulk
> URBs.
So queue one bulk URB per scatter/gather segment; no API change
necessary! Bigger segments are better; less per-segment overhead.
You could do that today ... but I notice us_transfer() won't try that.
Looks like today's bulk queuing model is a close match to what that
us_transfer() routine needs.
> Heck, I'd also like to put the status transfer on the end of that
> chain, so the CPU doesn't have to pay so much attention to the whole
> affair.
Well, each i/o segment will involve some CPU overhead. There's no
option; each one needs setup, teardown, checking. Some interrupt
mitigation can be done: the EHCI interrupt latency can be changed
(1-64 microframes, default 8 = 1/frame). For now, I suspect that a
lower-than-default latency is the right way to go.
Do you have enough statistics about those scatter/gather segments
to come up with a reasonable first-cut performance model? For
example, how big would each s/g segment be? How many segments
would get queued at a time? How many other (control/interrupt)
transfers go between each group of s/g bulk transfers?
I think the current bulk queuing has lots of mileage left. I'd rather
not change that unless/until we find we're hitting a wall with it.
- Dave
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
http://lists.sourceforge.net/lists/listinfo/linux-usb-devel
