On Fri, Oct 11, 2002, David Brownell <[EMAIL PROTECTED]> wrote: > > >>>-changed lowspeed control TDs from depth to breadth. > >> > >>Why for? This will guarantee that it will take (# of TD's * 1 ms) time > >>to complete. > > > > > > Well, mainly to make the code common...but also, making it depth opens the > > possibility (for a large transfer) of hogging the bus, and, will most > > lowspeed devices really be able to send more than 1 packet per frame? > > I thought the idea was to _prevent_ lowspeed transfers from hogging > the bus ... by limiting them to one transfer per frame?
That's very slow then. Control isn't guaranteed to be fair. However, uhci-hcd does provide a bit of fairness since it schedules new URB's to the tail. As a result, every URB will gets it's "fair" amount of time. The only thing that's unfair about the current implementation is that a NAK can slow it down, but that would be only once per frame. I don't think that's a significant source of slowdown. The real slowdown would be leaving spare time in the frame doing nothing. > All the other HCs apply a certain degree of round-robin logic to > promote fairness in silicon. UHCI has to do that in software. > I'd leave this part in. OHCI only does one TD per frame per transfer? 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
