On Fri, Oct 11, 2002, David Brownell <[EMAIL PROTECTED]> wrote: > > >>But Randy did provide usb_calc_bus_time() ... it was exactly the > >>right primitive, once it learned something about high speed! :) > >> > >>Not using those other calls because they were specific to URBs (not > >>endpoints), > > > > I don't see how your code is different in this respect. > > Think about how it works with queueing. The "cost" is stored > per-endpoint (modulo one optimization) which is where it needs > to be. It doesn't matter how many urbs are queued ... the only > time bandwidth utilization changes is when an endpoint gets > added to (or removed from) the periodic schedule. If the queue > length can only be one, it looks like the bandwidth is tied to > the urb, but otherwise ... > > There's also the balancing issue. In usbfs a single number is > shown, usec per frame. But a 640 usec transfer that runs once > every 32msec is not going to cost 640 usecs (out of 900 usec max). > You can run 32 of them at a time, with bandwidth left over. A better > solution is to report it as 640/32 = 20 usec. > > But clearly "20" can't be used to make scheduling decisions, since > it's just an average. In that scenario only 260 usecs is left > for every-frame transfers, not 880 usecs. Use all that, and your > average becomes 260+20 = 280 ... plenty of bandwidth available, > but you have ask for it with bigger periods. > > The uhci-hcd code isn't currently using per-endpoint data structures, > except maybe the ring of urb_priv queued to it. That'll make some > per-endpoint reasoning look a bit odd. But it could store a pointer > to one in its per-endpoint pointer, something like: > > unsigned index = usb_pipeendpoint (urb->pipe); > struct uhci_ep *ep; > > if (usb_pipein (urb->pipe) && !usb_pipecontrol (urb->pipe)) > index += 16; > ep = ((struct hcd_dev *)usb_dev->hcpriv)->ep[index]; > > Or maybe just store the last urb_priv from the ring. (I'd sort of > like to see a real "head of list" so it's more natural to use the > list primitives, like list_for_each_entry ...)
The problem with all of this is: a) It depends on queuing b) It doesn't reserve the bandwidth Each in itself make it unacceptable. Although a per frame bandwidth measurement might not be a bad idea. I wonder if that can be similified some. > > Perhaps you should have fixed the code he wrote? > > I certainly thought about that for a good amount of time before > fixing that code in this particular way. It still needs some more thought. > p.s. Re "I started out thinking that way ... then I got better." > From Monty Python and the Holy Grail: "But I thought you were > dead!" "I got better." Ahh. I completely missed the reference. JE ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
